This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
Subject: Re: /sbin in root's $PATH? From: rking@zengine.com (Ryan King) Date: Thu, 8 Jun 2000 02:14:42 -0700 Well, it seems like we've both been wrong on parts... On Wed, Jun 07, 2000 at 10:57:51PM -0700, Jeremy Katz wrote: > On Wednesday, June 07 2000, Ryan King may have said: > > > On Wed, Jun 07, 2000 at 08:25:49PM -0700, Jeremy Katz wrote: > > > On Wednesday, June 07 2000, Ryan King may have said: > > > > > > > Sorry if this is OT or a FAQ, but why does neither RH6.1 or RH6.2 include > > > > /sbin/ in root's path? > > > > > > > > I've been brainstorming to try to conceive of a case where this is > > > > advantageous, but have come up empty-handed and confused. Any insight > > > > will help ease my distressed soul. > > > > > > Umm... are you sure didn't just do a 'su' instead of a 'su -'? Just > > > running su by itself will inherit the environment already present intead > > > of getting a login shell for root. Logging in as root at a console > > > (something you should never do, but nevertheless :) gives me /usr/sbin > > > and /sbin both in my path as expected > > > > Ok, I see that that is the behavior. Then this means that this was not > > intentionally done, right? > > No, this is very intentionally done. It is actually the behavior of su > on every platform I can remember off the top of my head. Well, if you look at the login/shadow tarball, there are three files in etc/: login.defs login.defs.hurd login.defs.linux For login.defs, the path is this: ENV_SUPATH PATH=/etc/local:/etc:/local/bin:/usr/bin:/bin ...which expects for binaries to be in /etc/, and that's against the FSSTND, so we'll take it as a given that this doesn't apply. For login.defs.hurd: Neither ENV_PATH nor ENV_SUPATH are defined, so hey. For login.defs.linux, the path is: ENV_SUPATH PATH=/sbin:/bin:/usr/sbin:/usr/bin So it seems that the maintainer of the .rpm explicitly chose to deviate from the "standard" Linux behavior. Actually, the file in the RedHat package is a fraction of the size of the default one... I wonder what else is diverging? > > As much as I can't understand when one would want to have a /sbin/-less > > path as root, I can't understand why you would only want it to be there > > when you log in as root, and not when you su. (Because, of course, > > this encourages the iffy practice of logging > > in as root). > > When you run su, instead of su -, you are keeping the environment of > whatever user you were previously running as. Therefore, if this path > was trojan'd to contain, for example, /tmp:/bin:/usr/bin: ... and /sbin > and /usr/sbin got appended to this automatically, you might run a > command such as ifconfig without an explicit path and run /tmp/ifconfig > which is a shell script adding a root shell to /etc/passwd and > /etc/shadow. Interesting... this whole point hinges on the first assumption, which is that the entire environment is inherited. It isn't -- $PATH comes from whatever is in /etc/login.defs, either ENV_PATH for normal users or ENV_SUPATH for root. Example (extra newlines added): % whoami; echo $PATH; ~ rking /usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:/home/rking/bin % su cking ~ Password: $ echo $PATH; /usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games $ exit exit % su ~ Password: # echo $PATH /home/rking /usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/bin/X11:/usr/local/sbin:/usr/local/bin # exit /home/rking % su - ~ Password: # echo $PATH ~ /usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/bin/X11:/usr/local/sbin:/usr/local/bin With the above series of events in mind, I can't help but wonder where the comments about "Trojan Paths" comes from exactly? > The proper way to get a root shell is to do '/bin/su -'. This a) makes > sure you are running the su in /bin as well as runs it as a login shell, > giving you *just* root's environment, without environmental variables > for the user. This isn't always desirable though, eg, for the purpose > of running some X-based configuration tool and the default is to keep > the current environment due to the theory of least surprise. (Same as above). ===