Subject: Re: su -d ?
To: David Laight <david@l8s.co.uk>
From: Greywolf <greywolf@starwolf.com>
List: tech-userlevel
Date: 04/27/2003 13:27:18
Thus spake David Laight ("DL> ") sometime Today...

DL> I was actually thinking of the case where you need to su to root,
DL> but are deep within a directory hierachy and don't want to change
DL> the current directory.
DL>
DL> Using 'su root' is dangerous because it keeps all the baggage of the
DL> existing user - if ENV is set it will run that script as root (which
DL> is almost certainly not what you had in mind, never mind problems with
DL> some malicious user typing export ENV=xxx while you aren't looking).

Begging to differ, this seems a bit misguided.

1.  csh and friends have a built-in check to see if you own the .cshrc
	in question; if you don't, it doesn't get sourced.  Ditto .login.

2.  'su root' under NetBSD does NOT use the existing baggage of the
	existing user; it does so under Solaris and other SysV variants.
	This was, in fact, one of the things that REALLY peeved me about
	Solaris was that a 'su $user' did NOT attempt to use the .cshrc
	or .login.

I note that ksh does not offer similar protection, although bash does;
tested with BASH_ENV=$HOME/.bashrc su $my_superuser_acct, I do not
inherit a run of $BASH_ENV on either that shell or any subsequent shells,
even though it is set.  I find this rather interesting, actually.  It must
be a hack to prevent things going wrong with root.

Actually with bash, I note that BASH_ENV becomes explicitly UNset.
Must be another hack.  The rest of the envariables are intact.

That said, I think that ksh should be patched NOT to automagically use an
$ENV that does not belong to the invoking user.  This is the Right Fix.

DL> NetBSD's 'facility' of only allowing users in group wheel to run su
DL> may stop some of the biggest problems, but you should really use
DL> 'su - root'...

Only if you must.  'su - (anyone)' is more of a PITA for people who
know how to -- and do -- use the "suspend" command properly.

I use "su" and "su $my_superuser_acct" regularly with no environmental
invasion problems.

"su -d" would emulate the default Solaris behaviour of "su", for whatever
it would be worth.

				--*greywolf;
--
NetBSD: the second best thing you can get for free.