Mailing List Archive

[Bug 1494] doesn't look on path for $SHELL
https://bugzilla.mindrot.org/show_bug.cgi?id=1494


Damien Miller <djm@mindrot.org> changed:

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




--- Comment #2 from Damien Miller <djm@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.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 1494] doesn't look on path for $SHELL [ In reply to ]
https://bugzilla.mindrot.org/show_bug.cgi?id=1494





--- Comment #3 from Vincent Lefevre <vincent@vinc17.org> 2009-01-21 22:19:06 ---
(In reply to comment #2)
> My copy of Single Unix Specification states:

I'd rather use POSIX.1-2008.

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

POSIX.1-2008 says the same thing (note: just "pathname", not "absolute
pathname").

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

POSIX.1-2008 says more:

3.266 Pathname
A character string that is used to identify a file. In the context
of POSIX.1-2008, a pathname may be limited to {PATH_MAX} bytes,
including the terminating null byte. It has an optional beginning
<slash>, followed by zero or more filenames separated by <slash>
characters. [...]

Note: Pathname Resolution is defined in detail in Section 4.12
(on page 111).

It has also the notion of absolute pathname (when the pathname begins
with a slash) and relative pathname (when the pathname does not begin
with a slash).

> I'd say that a non-absolute pathname for $SHELL clearly does not
> "identify a file"

According to POSIX.1-2008, relative pathnames identify a file,
otherwise there would be only one kind of pathnames: absolute ones.
POSIX uses the term "pathname" also for execvp, for instance.

> 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.

Because it is context-dependent. For instance, relative pathnames are
sometimes resolved against the current working directory, not by using
$PATH.

IMHO, if POSIX wanted to disallow relative pathnames for $SHELL, it
would have said "absolute pathname". It does not say to use $PATH, but
this is implicit: in the PATH definition: "This variable shall
represent the sequence of path prefixes that certain functions and
utilities apply in searching for an executable file known only by a
filename." For $SHELL, we are also in the case of an executable.

--
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.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs