/sbin:/usr/sbin in mortal's PATH

[Paul Wouters]

> > `ifconfig` is _also_ for system administrators. Regular users — my
> > Oracle DBAs, say —
>
> Those aren't "regular users" by a /very/ long shot in my book.

In that case, there are no "regular users" on most linux servers. In which
case you only make the case for allowing commands like ifconfig to be used
by everyone (since most linux servers have no "regular users").

> > I also find it annoying that I either have to type the full path —
> > particularly as it means I have to remember which of
> > /bin:/usr/bin:/sbin:/usr/sbin the utility in questions resides in — or
> > become root just to check ifconfig output.
>
> Use aliases.

The point here was not that it was impossible to overcome. The point being
made was that a majority of the users want commands in /sbin and /usr/sbin
to be in their path, even if they do not have root permission on them.

> They are in /bin and /usr/bin. What is in /sbin or /usr/sbin is /not/ for
> regular user consumption. If they need it, they aren't regular users.

You are confusing "regular users" with "endusers that only click icons".
Those click-users are not running a terminal window, so they have no
issues with wether there are 2500 or 3000 commands in their path. However,
those who do run a terminal, tend to really enjoy using commands like
"ip", "ifconfig", "ping" and "traceroute".

> > Conversely, utilities that non-root users should not be allowed to use
> > need to be protected in an effective manner;
>
> ... by permission to run only by selected user/group, by internal checks in
> the utility, by permission checks in the kernel; where you /must/ rely
> only on the last for real security, just exactly as this has worked from
> day one (or thereabouts) in Unix...

This is not a security issue. No security is gained from needing to type
"/sbin/ifconfig" over "ifconfig".

> >                                              and removing the directory
> > from their path is not it. This isn't even security by obscurity, it's
> > security by obtuseness.
>
> It has nothing whatsoever to do with security, and everything with not
> confusing random users with commands they can't use sensibly.

Oh come on. A lot of unix commands are two letters long. This has nothing to
do with protecting the user, and has all to do with sysadmins wanting to
cut down on typing. 2500 vs 3000 commands is not going to make a different to
the enduser that "needs protection".

And on the other side, if we do believe we need to help and protect these users,
then i should file a bug report against "cal 5" because it displays the year 5
instead of the current year, fifth month.

Let's dump some legacy guys. I can understand /foo versus /usr/foo, as we can
still do shared /usr readonly mounts, but the distinction between /bin and /sbin
is silly. And that's why people here are annoyed by it, they always have to make
this change on any fresh install of redhat.

Paul