[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