openssh bugs - Jul 2008 - [Bug 1494] New: doesn't look on path for $SHELL

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

           Summary: doesn't look on path for $SHELL
    Classification: Unclassified
           Product: Portable OpenSSH
           Version: 5.1p1
          Platform: Other
               URL: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=49272
                    8
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: ssh
        AssignedTo: unassigned-bugs at mindrot.org
        ReportedBy: cjwatson at debian.org


In http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=492728, Vincent
Lefevre reported this regression in 4.9p1 and above:

"For a host for which I have a ProxyCommand:

vin:~> echo $SHELL
zsh
vin:~> ssh xxxxxx.xxxxx.xx
zsh: No such file or directory
ssh_exchange_identification: Connection closed by remote host

Note: POSIX does not require that SHELL contain a full pathname."

There doesn't seem to be any harm in using exec*p functions here. Patch
attached.

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

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





--- Comment #1 from Colin Watson <cjwatson at debian.org>  2008-07-29
19:52:40 ---
Created an attachment (id=1552)
 --> (http://bugzilla.mindrot.org/attachment.cgi?id=1552)
look on $PATH for $SHELL

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

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


Vincent Lefevre <vincent at vinc17.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vincent at vinc17.org




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

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.

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





--- Comment #3 from Vincent Lefevre <vincent at 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.

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX

--- Comment #4 from Damien Miller <djm at mindrot.org>  ---
WONTFIX - I don't accept that logic (you wouldn't specify
"zsh" as your
shell in /etc/passwd without a path). Furthermore, I don't think it is
too hard to specify a path when a user overrides $SHELL.

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

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

--- Comment #5 from Vincent Lefevre <vincent at vinc17.org>  ---
(In reply to comment #4)
> WONTFIX - I don't accept that logic (you wouldn't specify
"zsh" as
> your shell in /etc/passwd without a path).
I wouldn't do it because the environment (in particular, $PATH) at this
time may be unspecified. So, it wouldn't make sense. For SHELL, this is
different: when I set $SHELL, I already have a $PATH value that I
control.

Note that one of the reasons why I don't always have a full pathname is
that I do from my .zshenv:

[[ -o login ]] && SHELL=${0#-}

Then one may wonder why $0 doesn't have an absolute pathname...
> Furthermore, I don't think it is too hard to specify a path when a
> user overrides $SHELL.
Yes, for the use of SSH, probably.

Note that a relative pathname could still be useful in some context,
e.g. when one needs to set SHELL from a config file which accepts only
hardcoded values (e.g. no references to environment variables such as
$HOME) and that would be shared under NFS. However, I don't think this
is a problem as far as SSH is concerned (at least until now).

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

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #6 from Damien Miller <djm at mindrot.org> 2011-01-24 12:34:05
EST ---
Move resolved bugs to CLOSED after 5.7 release

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