[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

Paul Wouters wrote:
`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.

This really seems a bit unreal. If you want /sbin and /usr/sbin in your path, well
gee, that's what .profile or .bash_profile is for. Where in the world did this idea
of "root only" commands come from? If these were truly "root only" commands,
then /sbin and /usr/sbin would have 700 permissions. Long, apparently too long
ago, /sbin (and /usr/sbin) were reserved by informal convention for commands
that were statically linked, and thus did not require libs from /usr/lib, back in
the days when there was no /lib, so that on a flaky or corrupt system where /usr
could not be mounted for some reason, some few commands could still be run
to restore the system. One of the fundamental principles of *nix was that the
user was presumed to know what they were doing. That seems to no longer be
the case with Linux.

=== Ron Watson === rw compukitty com ===
  Nisi potestatam dabis, non habebunt.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]