Re: shebang-less script execution not resetting some options

[Ilkka Virta]

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