On Thu, Jun 08, 2000 at 01:17:51AM -0600, Chris Abbey wrote:
> At 22:46 6/7/00 -0700, Ryan wrote:
> >Ok, I see that that is the behavior. Then this means that this was not
> >intentionally done, right?
>
> it was intentional that root have /sbin and /usr/sbin in it's path
> *when root _logs_in_*
Ok.
>
> it was intentional that non-root not have /sbin and /usr/sbin in their
> path *for login shells*
Ok.
> it is intentional that *any user* who executes 'su' *retain* their
> current login environment (does not _log_in_ as new user)
Doesn't work that way (See my mail to Jeremy about this)
> it is intentional that *any user* who executes 'su -' gets a new
> *login shell* as the user they SwitchUser to (_logs_in_ as new user)
Ok.
> >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).
>
> are you perchane thinking "super user" when you type 'su'? it's historic,
> and I'm fairly sure intended, use is "switch user"... it's just that it
> happens to default to user root if you don't specify one. from `man su`:
> [...]
Funny thing about that is that you'll find conflicting facts about this if you look it
up.
It seems that BSD-based documents lean towards saying that it is "Switch User", and
more Linuxish (or SysV in general?) documents say it's "Super User".
According to the "Free On-line Dictionary of Computing", it's "Substitute User".
V.E.R.A. says "Switch User".
If you look at the su.c source file, you'll find this: "su - switch user id"
...which is interesting, because there are places within this code where "SU" clearly
means "Super-User", like ENV_SUPATH.
My conclusion is that it'd be nice to find the first instance of "su" and see what the
author says it means. Nothing like Unix history to get the old brain tied up in
knots. =)
> (historic note, I've heard that the default user id of root was
> a bug in the original Unix impl of su... the int userid was initialized
> as 0 and then would be assigned in the parsing of the command line options
> after the appropriate calls to get the numeric id from the username, but
> if you didn't specify one on the command line it happily went ahead and
> used 0.)
Interesting enough. I can't see how "root" wouldn't be a reasonable default user, but
by the same token I wouldn't put anything out of the "It's a Feature Not a Bug
Category". Being an engineer myself, I can say that I, too, have written my share of
FeatureBugs.
> >So why isn't it in /etc/login.defs? ENV_SUPATH should certainly contain
> >/sbin/, no?
>
> wow... what's /etc/login.defs... never seen that before... what's
> ENV_SUPATH? I've been using *nix for a while, and Linux for three years,
> never heard of that file before... and man is it ugly....
Lots of maaaagical stuff goes in there. (See man login.defs)
> >I'm just trying to understand if this is a bug or a conscious
> >decision... but I can't understand how it could be a bug (and have
> >remained unfixed for so long), or how it could be a conscious decision
> >(because that makes no sense).
>
> it's a concious decision aimed at making the distro more like comericial
> *nix boxen as near as I can tell.
(See mail to Jeremy about login.defs vs. login.defs.linux)
> If you're like me, rarely at the console, always admin the box across
> the net by logining in then su'ing you can either put the paths into
> your normal user path, or alias su="su --login"
(See other mail)
Maybe I'm missing something obvious, though.
- Ryan King
--
To unsubscribe:
mail -s unsubscribe [EMAIL PROTECTED] < /dev/null
