On Thursday, June 08 2000, Ryan King may have said:
> > 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."
The Shadow Suite. The Shadow Suite does not include su. su comes from
sh-utils. Additionally, and more importantly, check the date on that
HOWTO. April 3, 1996. Over four years ago. Which is an eternity in
Linux time. Much of the information in the document is out of date for
our current PAM-ified world ;)
> > > 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
Some of which are used -- mail information, password aging (though
again, this is handled more by PAM now), and UID boundaries. To address
a few of the other options referenced in the man page, in a fully
PAM-ified environment, most of these are handled by PAM. Those that
aren't are shell initialization issues and it is more expected to admins
from other Unices that these are defined in the shell initialization.
Even so, reading _exactly_ what is stated in the man page, ENV_SUPATH is
the PATH of the superuser, but login.defs is only used when logging in
(it's called login.defs for a reason :) and thus it's only the path when
you login as root. su != login
> > 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.
No, traditional behavior has no shadow-utils, and thus everything in
shadow-utils is non-traditional. Correctness is in the eye of the
beholder, but I see very little there that is not handled by PAM, or
that shouldn't be handled by PAM.
> > > 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)
Debian has not had a release _yet_ which is PAMified. Granting that
nobody who "runs" Debian runs Debian stable and instead runs the
unstable branch, there has been varying degrees of PAM support in Debian
for about a year now. But, this transition was still somewhat rough
around the edges the last time I checked (about 3 months ago). This is
to be expected as transitioning to PAM does cause some changes in
behavior that have to be adjusted to.
> > 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.
To get a "virgin" shell with the proper path for root, use '/bin/su -'.
It's in every book on system administration out there and one of the
first things to tell a junior SA. For the times you don't want a login
shell you can just run '/bin/su' or, stretching it, 'su' alone. Oh,
and my path was a terrible example there... I forgot that I have both
/sbin and /usr/sbin in my path as a normal user.
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:
Statistics are no substitute for judgement.
-- Henry Clay
PGP signature
