[Bug 1494] doesn't look on path for $SHELL

bugzilla-daemon at bugzilla.mindrot.org bugzilla-daemon at bugzilla.mindrot.org
Wed Jan 21 20:26:24 EST 2009


https://bugzilla.mindrot.org/show_bug.cgi?id=1494


Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org




--- Comment #2 from Damien Miller <djm at mindrot.org>  2009-01-21 20:26:23 ---
This is because of this commit to sshconnect.c:

> revision 1.201
> date: 2007/08/23 03:23:26;  author: djm;  state: Exp;  lines: +6 -3
> Execute ProxyCommands with $SHELL rather than /bin/sh unconditionally

We started using $SHELL to avoid ssh ProxyCommand support being a way
out of restricted shells like rbash. I'm not sure what the implications
of changing the execution to execlp() would be, but I think the
assertion that this behaviour is somehow supported by POSIX to be in
error.

My copy of Single Unix Specification states:

> SHELL
>     This variable shall represent a pathname of the user's
>     preferred command language interpreter. [...]

Its definition of "pathname":

> A character string that is used to identify a file. 
> [...]
> Note:
>     Pathname Resolution is defined in detail in _Pathname Resolution_.

I'd say that a non-absolute pathname for $SHELL clearly does not
"identify a file" unless one happens to be in the same directory as the
shell itself and the "Pathname Resolution" section doesn't specify that
pathnames be resolved using $PATH.

Depending on $SHELL to be resolved by $PATH is at best
implementation-defined, and IMO probably only works by accident.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.


More information about the openssh-bugs mailing list