Re: /etc/profile should include sbin in PATH
gsstark@MIT.EDU (Greg Stark) wrote:
> ... there are many programs in sbin that are useful for ordinary users
> including the two explicitly listed in the FSSTND, traceroute and
> ifconfig.
Hmmm... Let's see. From the ifconfig(8) man page:
NAME
ifconfig - configure a network interface
DESCRIPTION
Ifconfig is used to configure the kernel-resident network
interfaces. It is used at boot time to set up interfaces
as necessary. After that, it is usually only needed when
debugging or when system tuning is needed.
Thus, ifconfig's own documentation appears to state that ifconfig is
an administrator's tool. Indeed, I think that you are too focused on
classifying a tool as "useful for ordinary users" if there is even a
remote possibility that it might be run by an ordinary user. Instead of
focusing of what a user *might* run, I prefer to focus on the purpose of
each utility. There are many programs that are primarily intended to be
used for administrative purposes. While we can debate what tasks can be
classified as administrative, personally, I feel that anything that sets
up, configures or analyzes devices, network interfaces, etc. *should*
be classified as an administrative tool. I also feel that this should
include such tasks as analyzing the network.
If a user periodically needs to perform such administrative tasks under
his user account, he can modify the path on that account. That's pretty
easy to do. There are many users, however, who will never need to run
any of these administrative commands (even you must admit that), and
therefore, do not need them in their path.
> I personally don't buy this logic at all for two reasons:
> 1) Nobody has been able to explain why these programs are a "burden"
We should not need to explain why these programs are a burden. You are
the one who wants to change things. If you want to play these games,
then you should explain why it is such a "burden" for you to add /sbin
and /usr/sbin to the path of your account.
> 2) What can be usefully run as an ordinary user can vary based on the
> local administrator policy. lsof may be a setuid on one system
> whereas ping is made unsetuid on another system. /dev/loop[0-9] may
> be writable by group disk on one system whereas group disk may be
> empty on another.
And such cases should be handled by the local administrator, not us,
the distribution builders. They can easily be handled by an energetic
administrator by adding a symlink to /usr/local/bin.
> 3) There is no precedent in Unix for separating binaries based on
> their intended users. The only example is one that mostly just
> causes headaches and problems, /usr/X11R6.
What about /usr/bin/mh -- used by MH, the most Unix-like of all MUAs?
All MH commands are placed in their own directory, and rightly so. Not
only is it unnecessary for these commands to be in the an ordinary
user's path, it is dangerous, since a user who is not familiar with MH
can, by misspelling a similar command, mistakenly run one of the MH
commands and mess up his mailbox and his account. There is no reason to
run one of MH's commands (even by mistake) if the user's account is not
set up to use MH, and there is no reason for these commands to appear in
the path.
As another example, consider the Unix practice of listing its
administrative commands (system management commands) in a separate
section of its documentation (section 8 of the man pages). This was
done so that ordinary users of a Unix system can focus on section 1,
the user's commands, and not worry about system administration. If
these administrative commands are not documented in the same section as
ordinary commands, I think that it is sensible to place them in their
own directory.
Please don't tell me that there is no precedent in Unix for separating
binaries based on their intended users. That is simply not true.
> I guess I propose that either of two things happen:
> 1) /sbin and /usr/sbin are put into everyone's path.
That is not necessary. It eliminates the whole point of separating the
binaries in the first place.
If you want to place /sbin and /usr/sbin in your path on your system, or
place them in the everybody's path on the systems that you administrate,
then fine; that's your own business, and it's not very difficult to
do. Please however, do not stick these two directories in MY path just
because you fail to understand the difference between administrative
work and ordinary work.
> 2) Debian Policy explicitly include language listing the types
> of programs that we consider "only generally useful to system
> administrators". Either that or an unambiguous set of objective
> criteria to test. Personally I suggest only "system daemons that
> cannot be run without root privileges and configure scripts that
> cannot save their configuration changes without root privileges"
> Note that this would mean some daemons would be in /usr/bin and
> some in /usr/sbin.
One aid for this type of decision is the section that contains the
program's man page. Place section 1 commands under /bin or /usr/bin
and reserve /sbin and /usr/sbin for section 8 commands. Note that both
ifconfig and traceroute appear in section 8 of the manual, under "System
Management Commands." Of course, this method is not infallible. For
example, the ping man page appears in section 8, but the FHS explicitly
states that it should go in /usr/bin.
> or there's a third solution
> 3) abolish /sbin and /usr/sbin and put these binaries in /bin and
> /usr/sbin. Make symlinks so scripts still work.
Bad idea. Not only is it ugly and difficult to accomplish, it serves
little purpose, other than to raise the entropy of our filesystem
layout.
Brian
Reply to: