[sf-lug] /usr/sbin

[Rick Moen]

Quoting Alex Kleider (akleider at sonic.net):

> Some of you may remember my mentioning (on more than one occasion)
> that some utilities seemed not to come with Debian.
> Some responded (Rick and Michael if I remember correctly) with what
> I interpreted to be incredulity/skepticism.  They were right of
> course but I can now explain the problem and believe it to be one
> worth sharing.
> 
> The Debian install comes with PATH set to a value that does _not_
> include /usr/sbin which is where the 'missing' utilities lie.
> Surely this should be considered a 'bug' with regard to the Debian
> distribution, n'est pas?

No.[0]

As you may know, utilities in /usr/sbin and /sbin are ones normally used
only by the superuser.  The default $PATH for the root user includes those.
Observe:

  [rick at linuxmafia]
  ~ $ echo $PATH
  /usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:/home/rick/bin:/home/rick/bin
  [rick at linuxmafia]
  ~ $ su -
  Password:
  linuxmafia:~# echo $PATH
  /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11
  linuxmafia:~# exit
  [rick at linuxmafia]
  ~ $

On rare occasions, a non-root user might have cause to run something in 
/sbin or /usr/sbin :  The classic example is /sbin/ifconfig .  But you 
come to know where they are from the rare occasions where you need them,
and you just furnish the path from memory, e.g., my fingers do
'/sbin/ifconfig' with the aid of shell tab completion without my having
to think about it.


The reason /sbin and /usr/sbin should not be in $PATH for non-system
users is that it creates various security risks[1], and many of the
utilties in those directories are dangerous.

Oh, and the reason my shell session above has 'su -' instead of 'su' is
to carefully avoid the root user inheriting the non-superuser's shell
environment, which again would be a security risk, so make a point of 
always including that switch when su-ing to root.



[0] Occasionally, a newcomer opens up a bug to that effect against
Debian.  It gets closed with a polite explanation about why this is
an intentional $PATH omission.

[1] The reason I'm being vague, here, is that I've forgotten details, 
and can't take the time to re-research that, at present.