On Thursday, June 08 2000, Ryan King may have said:
> 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
The file is called "login.defs". It is executed by login. Therefore,
it is executed when you have a login shell. You do not have a login
shell when you just run 'su'.
> 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.
/etc is the historical location for system binaries. They were then
moved to /sbin in the SysV transition if I remember correctly. (note:
when it changed it quite likely to be wrong; essence of the idea is
correct)
> 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?
The package is using the login.defs from the 19970616 release of
shadow-utils, likely for reasons of back compatibility. Additionally,
in a pamified environment, a lot of what shadow-utils provides is less
useful; this wasn't the case when you had to manually convert to
shadowed passwords.
> > > 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.
Again, /etc/login.defs should only be sourced by login and I'm not
certain that it's even used there anymore in most cases.
> Example (extra newlines added):
[snipping of full paths to conserve bandwidth]
> With the above series of events in mind, I can't help but wonder where
> the comments about "Trojan Paths" comes from exactly?
Not entirely sure what you installation is doing -- what version of Red
Hat are you running? I get exactly the behavior I described here on a
machine running Red Hat 6.2
1057 katzj@nebula:~> echo $PATH
/home/katzj/bin:/home/katzj/bin:/home/katzj/bin:/opt/kde2/bin:/bin:
/usr/bin:/usr/bin/X11:/usr/local/bin:/usr/bin:/usr/X11R6/bin:/usr/local/bin:
/usr/sbin:/home/katzj/scripts:/usr/X11R6/bin:/usr/local/bin:/usr/sbin:
/home/katzj/scripts:/usr/local/bin:/usr/sbin:/home/katzj/scripts
1058 katzj@nebula:~> su
Password:
[root@nebula katzj]# echo $PATH
/home/katzj/bin:/home/katzj/bin:/home/katzj/bin:/opt/kde2/bin:/bin:
/usr/bin:/usr/bin/X11:/usr/local/bin:/usr/bin:/usr/X11R6/bin:/usr/local/bin:
/usr/sbin:/home/katzj/scripts:/usr/X11R6/bin:/usr/local/bin:/usr/sbin:
/home/katzj/scripts:/usr/local/bin:/usr/sbin:/home/katzj/scripts
[root@nebula katzj]#
As opposed to
1124 katzj@nebula:~> echo $PATH
/home/katzj/bin:/home/katzj/bin:/home/katzj/bin:/opt/kde2/bin:/bin:
/usr/bin:/usr/bin/X11:/usr/local/bin:/usr/bin:/usr/X11R6/bin:/usr/local/bin:
/usr/sbin:/home/katzj/scripts:/usr/X11R6/bin:/usr/local/bin:/usr/sbin:
/home/katzj/scripts:/usr/local/bin:/usr/sbin:/home/katzj/scripts
1125 katzj@nebula:~> su -
Password:
[root@nebula /root]# echo $PATH
/opt/kde2/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:
/usr/bin/X11:/usr/X11R6/bin:/root/bin
[root@nebula /root]#
Jeremy
--
Jeremy Katz
[EMAIL PROTECTED] | [EMAIL PROTECTED]
http://linuxpower.org | Developer, NCSU Realm Kit for RHL
GPG fingerprint: 367E 8B6B 5E57 2BDB 972A 4D73 C83C B4E8 89FE 392D
QOTD:
Counting in binary is just like counting in decimal -- if you are all thumbs.
-- Glaser and Way
PGP signature
