[sf-lug] /usr/sbin

[Michael Paoli]

references/excerpts - my comments and such in-line
... and I'll try not to be too redundant ;-) ...

> From: "Alex Kleider" <akleider at sonic.net>
> Subject: Re: [sf-lug] /usr/sbin
> Date: Fri, 15 May 2020 14:06:10 -0700

> On 2020-05-15 12:36, Rick Moen wrote:
>> 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.

Oh, that depends quite a bit ... like how (non-)minimal an installation
one does/doesn't do/have.  Debian has over 59,000 package available, so
(if one is systems administrator thereof) one can generally install
it if it's desired, and not already there ... but I(/we) digress ...

>>> 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?

Rick mostly addressed it, but in brief, superuser (root), by
default, has /usr/sbin (and if applicable, /sbin) on PATH,
whereas mere mortal users, do not.

>> 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.

I might be inclined to state things slightly differently,
whether that's materially/significantly different, may be another
question.

So, yes, various stuff properly goes in /sbin and /usr/sbin,
rather than /bin and /usr/bin.
See also:
Filesystem Hierarchy Standard (FHS):
https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html

And, why is that /sbin and /usr/sbin not by default on mere mortal
users' PATHs?  A few reasons:
o Most of the stuff there they don't have permissions to use
o A lot of the stuff there is "dangerous" (at least historically)
   system utilities - intended primarily (if not exclusively) for
   the careful use by superuser (root).
o Much of what's there, would "mostly" just "confuse" many
   "mere mortal users" - e.g. they may often find themselves,
   perhaps often inadvertently running or attempting to run
   command, that they can't run, or can't do most of what they might
   think the command could/should do (like if they actually glanced at
   relevant man page), or they find, as mere mortal user, has such
   limited functionality they mostly/typically don't care for or
   about that command.
o In many cases, there may be another command, of same, or similar
   name, otherwise distinguished only by where it's located.  This can
   also cause confusion, etc. and especially so if mere mortal users
   have /sbin and/or /usr/sbin on their PATH before /bin and /usr/bin.
o sysadmins, avoiding a whole lot 'o questions from mere mortal users
   about stuff in /sbin and /usr/sbin that they can generally do little
   with anyway
o etc.

>> 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.

Eh, I don't know that I'd call it security risk ... well
unless you count mere mortal users accidentally shooting themselves
in the foot, and highly equipping them to do so, to be a security
risk ... perhaps so.

>> 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.

Yep, some of us learned and/or had this drilled into our heads long
long ago.  In generally, one wants to use:
su - [user [options ...]]
rather than:
su [user [options ...]]
... period.
With the -, one gets an environment and such, very much as if one had
logged in as user.  Without the -, a whole bunch of the invoking
user's environment and such goop is dragged along - that's generally
a bad thing (I'm not going to elaborate on that - others may feel
free to do so).

> Once again, Rick, you've clarified the situation.
> I did not know the difference between
> su
> and
> su -
> .
>
> Having in the past always used the former, I was (as you've  
> explained) inheriting $PATH from non privileged user and not having  
> access to /usr/sbin.

PATH and/or other environment bits and such, but yes.

Also, some distros have more recently changed to versions/implementations
of su that come closer to the documented, historic, and standards based
behavior of su, whereas some other implementations/versions of su - at
least along the way, have more significantly deviated from that.  So,
also, many folks, from that, have gotten into comparatively
bad habit of using su without -, as it gave them behavior "close enough"
to with -, that they didn't find it problematic ... until the su behavior
was corrected, and folks started getting behavior they should've always
gotten earlier, but weren't expecting and ready for that.
E.g.:
https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#su-environment-variables