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

Groups > gnu.bash.bug > #15451 > unrolled thread

Re: shebang-less script execution not resetting some options

Back to article view | Back to gnu.bash.bug

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

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

#15451 — Re: shebang-less script execution not resetting some options

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

[toc] | [standalone]

Back to top | Article view | gnu.bash.bug

csiph-web