Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > gnu.bash.bug > #15451

Re: shebang-less script execution not resetting some options

Show key headers only | View raw

On 2.10. 13:11, L A Walsh wrote:
> On 2019/10/01 05:41, Greg Wooledge wrote:
>> On Tue, Oct 01, 2019 at 04:14:00AM -0700, L A Walsh wrote:
>>    
>>> On 2019/09/30 14:39, Grisha Levit wrote:
>>>      
>>>> A few of the recently-added shopt options aren't getting reset when
>>>> running a shebang-less script, this should fix it up:
>>>>    
>>>>        
>>> Suppose the shebang-less script is being run by an earlier version
>>> of bash.  Won't the new patch radically change the behavior of of
>>> such programs?
>>>      
>>
>> Bash allows a child of itself (a subshell) to read the commands.
>> GNU find -exec uses /bin/sh to run it.
>> zsh and csh both use /bin/sh to run it, I think.
>>    
> ----
>      So if a user has 'rbash' in /etc/passwd, they might get a real shell
> because various programs ignore what /etc/passwd says?
> 
>      Um....I suppose no one cares for one reason or another.

-------
   2.9 Shell Commands
   Command Search and Execution

   If the command name does not contain any <slash> characters, the first
   successful step in the following sequence shall occur:

   [a to d: functions, special builtins, stuff like that]

   e. Otherwise, the command shall be searched for using the PATH
      environment variable
      [...]
      b. Otherwise, the shell executes the utility in a separate utility
         environment (see Shell Execution Environment) with actions
         equivalent to calling the execl() function...

         If the execl() function fails due to an error equivalent to the
         [ENOEXEC] [...] the shell shall execute a command equivalent to
         having a shell invoked with the pathname resulting from the
         search as its first operand, [...]

[ 
https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/utilities/V3_chap02.html#tag_18_09_01_01 
]

-----

I think that last sentence above is the relevant part. The standard only 
says to "invoke a shell". It doesn't say which shell, probably because 
it only specifies one.

Incidentally, it doesn't really specify the hashbang either. As far as I 
can tell, it only mentions it as one of two ways that implementations 
have "historically" recognized shell scripts. (The above being the other.)

[ 
https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/functions/execl.html 
]


As for rbash, does it matter? If you let a user exec() something, 
they'll get that binary, or the interpreter specified in the hashbang if 
it's a script. The kernel doesn't look at /etc/passwd to recognize rbash 
or such either, so if you want to restrict a user from launching 
particular commands, you'll have to do it before exec() is attempted.

That is to say, don't let those users run (other) unrestricted shells, 
or any of the various programs that allow forking off other programs, 
including find, xargs, many editors, etc.


-- 
Ilkka Virta / itvirta@iki.fi

Back to gnu.bash.bug | Previous | Next | Find similar | Unroll thread

Thread

Re: shebang-less script execution not resetting some options Ilkka Virta <itvirta@iki.fi> - 2019-10-02 13:49 +0300

csiph-web