Allright, I'd like to start off by saying you were very right that
the most proper way to su is to 'su -', and that I wasn't doing that.
The first machine that I had root access on was configured to use
ENV_SUPATH and override the user's $PATH when su'ing, even without the -.
I'd even seen the note in the manpage about -, but didn't get in the
habit of using it.
At the same time (maybe this is what I should have said at the start),
the fact remains that the 'su' that comes with the Shadow Suite does
the above by default, and that the maintainer is diverging from that.
Whether or not the first su, or "commercial su"'s behave[d] so that
$PATH's were inherited or not doesn't matter... It's a dangerous thing
to do.
Given what you were saying about trojaned paths, I think it would take
compelling motivation to change the way the Shadow Suite behaves.
RedHat has changed the way the Shadow Suite works. I'm still trying to
figure this part out.
PAM or no PAM, there are things in login.defs, like ENV_SUPATH, that
are stunningly relevant.
On Thu, Jun 08, 2000 at 07:16:04PM -0700, Jeremy Katz wrote:
[ Relocated from below ]
> > > The package is using the login.defs from the 19970616 release of
> > > shadow-utils, likely for reasons of back compatibility. Additionally,
Ok, I couldn't find the 19970616 release anywhere on the web, and then
I double-checed, and found out that shadow-19990827 is actually in use.
I don't know where RH6.{1,2}'s /etc/login.defs comes from, but it's
nothing like anything you can find in shadow-19990827.tar.gz
> 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 ;)
Umm... ok, from the file /usr/doc/shadow-utils-19990827/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.
And if you doubt that su is a part of the shadow suite, you can download
the source tarball and look for src/su.c.
> 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
Yes, that's the way RedHat's su works.
No, that's not the way that the default Shadow "su" works.
Have you ever looked at the contents of a shadow-*.tar.gz?
> 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.
I don't really want to start a Debian war, so I'll decline to comment
about things like quality release cycles and apparent getting-boxes-sold
motivations of certain commercial distros.
> 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.
You're right completely, here, but my above points still stand.
- Ryan King
--
To unsubscribe:
mail -s unsubscribe [EMAIL PROTECTED] < /dev/null
