We're talking about two different items here:
1) The way the shadow package is configured by default, and
2) The way RedHat does it.
I'm trying to do two things:
1) Illustrate the stark difference between the two, and
2) Try to figure out why there is a discrepancy
> > 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'.
This is not the normal case, this is the RedHat case. From the "Shadow Password
HOWTO":
"7.3 The login.defs file.
The file /etc/login is the configuration file for the login program and also for the
Shadow Suite as a whole."
> > 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)
I was just trying to illustrate that there are three example login.defs that come with
the shadow package, and that there was only one relevant to Linux (login.defs.linux).
That one violates the FSSTND and is therefore completely not worth looking to for a
proper policy.
> > 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.
That sounds perfectly reasonable... sorry for not doing more research there. At the
same time, there are plenty of options that still are relevant even in a PAM'd
environment. See http://www.ioresult.t.se/io/linux_man/man5/login.5.html
> 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.
And, again, this is not the traditional, or IMHO correct behavior.
> > 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
That was an example session using what I believe to be a properly configured setup.
(It happens to be a stock Debian/Woody configuration)
> 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
I don't understand when this behavior is useful, or safe. The "Trojaned
Path" is enabled by this and completely impossible without it.
- Ryan King
--
To unsubscribe:
mail -s unsubscribe [EMAIL PROTECTED] < /dev/null
