bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: shebang-less script execution not resetting some options


From: Ilkka Virta
Subject: Re: shebang-less script execution not resetting some options
Date: Wed, 2 Oct 2019 13:49:58 +0300
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:60.0) Gecko/20100101 Thunderbird/60.9.0

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 / address@hidden



reply via email to

[Prev in Thread] Current Thread [Next in Thread]