Re: Odd reproducible problem - but is it a bug?
On Wed, May 04, 2022 at 07:04:52AM -0600, Charles Curley wrote:
> On Wed, 4 May 2022 05:23:31 +0200
> Anders Andersson <pipatron@gmail.com> wrote:
>
> > On this note, I've always found it annoying that debian (and likely
> > others) don't put /sbin in the normal user's $PATH. A lot of the tools
> > there have uses other than modifying the system.
>
> It can be annoying, but for good reason. In a multi-user system (such
> as Unix), it is a good security precaution to reserve programs that can
> modify or even inform the user about the state of the system to trusted
> users, such as root or wheel. Hence regular programs for regular users
> go into directories called bin, and system programs go into directories
> called sbin, and paths are set accordingly.
That is the most ludicrous thing I've heard in... a long time.
If a command can reveal sensitive information to an unprivileged user,
then "hiding" it in /sbin is not a valid security measure. The smart
user will simply run /sbin/whatever, or change their PATH variable to
include /sbin.
Of course, your assertion that any command *could* reveal such sensitive
information is laughable. Programs can only do the things allowed by
their privileges. If joe tries to read the /etc/shadow file, he can't
do it, because he doesn't have the correct privileges. None of the
commands in /sbin are going to be able to do it either, because they
run *as joe*.
(Obviously, setuid or setgid programs could exist which run with elevated
privileges. Those have to be written correctly. If one of them has a
security hole, just hiding it in /sbin *does not count* as a security
improvement on your system.)
> Even on a single user system the distinction is worth retaining. If
> nothing else, one occasionally needs a reminder to be careful with
> certain programs lest one shoot oneself in the foot.
There are several reasons why /sbin exists, historically.
On some systems, the programs in /sbin are *statically linked*. That's
what the 's' actually stands for -- not 's'ecure, not 's'uperuser, but
's'tatic. They're needed during boot, at a time when the file system
which contains the shared libraries used by commands in /bin may not be
mounted yet.
HP-UX is one such system. /bin is a symlink to /usr/bin, and there are
both /usr/bin/cat and /sbin/cat commands. Shell scripts which must run
during the early stages of boot can use /sbin/cat (along with redirections)
to copy files, or display simple messages.
On most other systems, the programs in /sbin are not statically linked,
but are placed there for other reasons.
One reason is simply that these programs don't *do* anything useful or
helpful for ordinary users. They may not even run at all.
Another reason is to reduce the size of the /usr/bin and /bin directories,
for performance. It's a tiny gain, but over years of operation, it could
add up to something noticeable.
The main reason is "because that's where it has always been". This is
both for user expectations, and for backward compatibility in case some
idiot hard-coded /sbin/ifconfig in a shell script. Keeping the commands
in their historic locations will prevent a few badly-written scripts
from breaking.
Reply to: