Bug 17909 - Sshd doesn't place /usr/local/bin in the path. UseLogin is broken.
Sshd doesn't place /usr/local/bin in the path. UseLogin is broken.
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: openssh (Show other bugs)
7.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-09-29 17:23 EDT by Andy Wang
Modified: 2008-05-01 11:37 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-11-20 15:04:21 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Andy Wang 2000-09-29 17:23:38 EDT
sshd doesn't place /usr/local/bin in the path.  Telnetd does this through
/bin/login.  UseLogin in sshd_config doesn't work. 
It appears sshd is using /usr/bin/login which RedHat doesn't have.  I
haven't tried creating a link so I don't know if
there are any other issues involved.
Comment 1 Gerald Teschl 2000-09-30 10:53:28 EDT
Linking /usr/bin/login to /bin/login  will make it work.
Comment 2 Pekka Savola 2000-09-30 16:44:38 EDT
The latter problem is a duplicate of #17835.

The former is caused by the fact that sshd sets $PATH to the same value 
$PATH was at the time it was compiled with.

The alternative is to tweak/upgrade RH's buildsystem or use 
--with-default-path=PATH.
Comment 3 Nalin Dahyabhai 2000-10-01 21:04:18 EDT
We're prepping a bug-fix errata to address this.
Comment 4 Michael Tokarev 2000-10-08 08:00:09 EDT
Just setting up --with-default-path=XXX does not solve the problem,
at least in a way redhat did this in openssh-2.2.0p1-2 in rawhide.
The rawhide's change breaks root logins:

  in original openssh path will be /usr/bin:/bin:/usr/sbin:/sbin
  in redhat's version it is /usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin

thus, /usr/sbin and /sbin isn't included even for root.  /bin/login
uses different paths for root and other users.
BTW, having /usr/local/bin in default path is a _BAD_ idea at all
(and this particular "bug" isn't a bug either) -- if a site needs
some local additions, it should be set up locally to add /usr/local/bin
to default path.  Redhat should _not_ include this into PATH by default,
since all programs shipped installed in standard places.
If /bin/login by default sets /usr/local/bin in PATH, then it is a login
bug.
Comment 5 Pekka Savola 2000-10-08 08:54:52 EDT
Yes, */sbin seem to be missing if directly logged on with root.  Usually people do 'su -' though which
avoids this.

A long-term solution would probably be to to add a check in /root/.bash_profile.  Similar things
have already been done for tcsh.  I'm doing the following, myself:

if [ "`echo $PATH | grep -c /sbin`" = "0" ]; then
  PATH="/usr/local/sbin:/usr/sbin:/sbin:$PATH"
fi

Not an optimal solution, especially if /usr is not mounted, but something to think about.


I'm of different opinion about /usr/local/{,s]bin though.  It's established that these dirs do contain local binaries.  
If someone does install local binaries, they are usually meant to be used, thus these dirs should be in 
path by default.

Nalin: I'm not sure if BuildPreReq'ing /usr/bin/rsh (in Rawhide 2.2.0p1-2) is a good idea.. it's an optional 
(and deprecated) package after all..
Comment 6 Michael Tokarev 2000-10-08 16:33:28 EDT
BTW, the "orthogonal" view on paths.  Is this a PAM work to set up PATH
variable?  It will be most general solution -- to have "pam_path" (or
use something that already exists (maybe) -- pam_env) that sets initial
path based on some criteria, say, username, group, or uid (having a file
that lists possible values, keyed on wildarded user/group/uid).

But -- the whole story seemed to be about rather unusual cases where shell
isn't executed.  If it _is_ executed, and looked to /etc/profile (or similar
for other than bourne shells), then the whole story is not an issue, since
there is always ok to set PATH in /etc/profile.

For root's .bash_profile, I'd recommend just setting the PATH as it should
be, not appending/prepending things. (Btw, the same should probably be in
system-wide /etc/profile).

And about BuildPrereq.  Not a _big_ issue, but I agree with pekkas@netcore.fi --
openssh.spec should specify explicitly where things should be searched
(/bin/login, /usr/bin/rsh etc) rather than allowing ssh's configure to
figure this by its own.  Also about this -- I saw in several rpms the
"technique" used for such a "pre-set" things (don't remember the rmps
for the moment, but I was forced to correct this).  .spec file creates
config.cache file with some values and after that executes ./configure.
It is far simpler to do something like
  ac_cv_var1=val1 ac_cv_var2=val2 ./configure ...
(or similar thing using export with %configure) than creating config.cache.
For this particular issues, relevant AC variable is
  ac_cv_path_LOGIN_PROGRAM_FALLBACK
for login (to be /bin/login) and --with-rsh=/usr/bin/rsh option for rsh.

Comment 7 Pekka Savola 2000-10-08 17:07:04 EDT
An issue to note: _absolute_ path is set nowhere in bash or tcsh initialization 
scripts; it's always just incremented. It has been set at compile time IIRC,
which makes sshd's work a bit harder for unified environment.

One approach might be to #ifdef out (or equivalent)

                child_set_env(&env, &envsize, "PATH", _PATH_STDPATH);

in session.c.

Comment 8 Nalin Dahyabhai 2000-11-20 15:04:18 EST
The errata candidate at http://people.redhat.com/nalin/test/ should now mimics
the behavior of login exactly (including the whole /usr/local mess).

Note You need to log in before you can comment on or make changes to this bug.