Re: /etc/profile should include sbin in PATH
Anthony Towns <aj@azure.humbug.org.au> writes:
> Note that traceroute is a network diagnostic tool: it doesn't actually
> change the local setup at all (as compared to, say, ifconfig).
ifconfig is also useful for developers and normal users, really it is.
> Note that traceroute is setuid,
Indeed having setuid programs in /usr/sbin is simply nonsensical if you adopt
the new interpretation of sbin. Think about it.
> Personally, I don't have sbin in my PATH as a user: that means I get a
> `command not found' error when I try to sysadminy things when I'm not
> root. I find that quite pleasant. OTOH, I have a symlink to traceroute
> from /usr/local/bin. But please stop telling me I'd be much happier if
> I just stuck sbin in my PATH. I wouldn't.
My real complaint here is that the very concept of separating between
"sysadminy" things and "normal" things is offensive to the Unix architecture.
It runs contrary to the design of the kernel, the Unix API, the shell,
everything. One fundamental underlying design philosophy in Unix is that all
users whether developers, users, or administrators, are equivalent.
Add to that the fact that very idea of separating binary directories based on
the expected uses of the binaries is also contrary to the overall design of
the hierarchy and we have a double whammy.
This case is just as bad as /usr/X11R6. In both cases there are a) no clear
criteria to use to judge which directory to place things and b) no
identifiable advantages to the division (of course if we had (b) then it would
be easier to define (a).)
Developers are also a special class of users, should we have a /usr/dbin for
developer stuff? After all I can't count how many times I've typed ld instead
of ls, which must be a much worse problem than people accidentally typing
ifconfig. Where does it stop? Of course we would need /dbin, /usr/dbin, and
/usr/local/dbin...
If I were designing the FHS I might put in /usr/sbin only system daemons or
other binaries intended to _never_ be run on the command line by _any_ user
under normal situations. Things like inetd, ftpd, etc. That has an
identifiable goal of preventing root from accidentally running a daemon when
he or she intends to use diagnostic tools. And it has the possibility that
those binaries would be modified less often and be more security critical and
therefore want to be on a different partition, for example. The FHS is so
vague that a system laid out this way would actually satisfy the requirements.
> Cheers,
> aj, who wouldn't mind if traceroute moved, but is really quite happy with
> where everything else is
Why is lsof in /usr/sbin? It's not a sysadminy thing even a little bit.
(fuser is in /bin for comparison... why "/bin" ?!)
What about losetup -- which is no more a sysadminy thing than mount or mtools.
Why is "logger" in /usr/bin when it's really only useful for the sysadmin?
Why is stunnel in /usr/sbin? The answer is because it's a dual purpose
program, it's a daemon and so it's very sysadminy, but it's also useful as a
development tool like socket or netcat, so it's very useful on the command
line with non system administration purposes.
The very fact that dual purpose programs are possible and even common, hell
one of the standard configuration tools, ifconfig, is such a dual purpose
program, spells out why the distinction is so pointless to make.
--
greg
Reply to: