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).
- Ryan King
--
To unsubscribe:
mail -s unsubscribe [EMAIL PROTECTED] < /dev/null
