Re: /etc/profile should include sbin in PATH
brian@debian.org (Brian Mays) writes:
> > 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.
I think before we make running any program more awkward the burden of proof
should be on the people who argue this is necessary. I've given a number of
cons for having programs made arbitrarily awkward for no apparent gain.
Essentially the problem boils down to a paternalistic attitude towards users
that has no place in Debian. Putting binaries that users can usefully run in
an intentionally awkward place because we've decided they probably don't want
to be running them and it might confuse them to see the completion is just
insulting and counterproductive.
The fact is that a "normal" user includes not just people who use staroffice
to write office memos, but also programmers, network engineers, etc. The
people I know use ifconfig on a nearly daily basis just to see what ip address
they're on so they can test network code. This is typical, and attempting to
decide in advance which programs will be run by "normal" users will find
exceptions everywhere. Saying these are exceptions is pointless, the real
lesson is that this isn't a useful distinction to be drawing.
> > 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.
If such cases should be handled by the local administrator then there
shouldn't be a /sbin or /usr/sbin. You're advocating the distribution making
this choice and forcing the local administrator to work around the
distribution. The distribution should be making lives easier not harder. If
this division served some greater purpose then it might be worth the pain, but
this pain seems to be the actual goal of the division.
> > 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?
I'll note mh is hardly ever installed like this any more. I've never seen it
installed like this, all the binaries are now typically installed in the
user's 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.
I'll note that section 8 is still searched by default. If you want to have a
/sbin and /usr/sbin but put it in everybody's path I would consider that a
useless irregularity like /usr/games and /usr/X11/bin but with few problems
since at least it wouldn't cause user confusion and annoyances.
> 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 spoke too fast. One precedent comes to mind, /usr/games. I think the
motivation for that had to do with having NFS exported score files use a
different set of permissions. But these days that would obviously be laid out
differently anyway.
Other examples of add-ons imposing this structure on Unix are things like X11,
Athena, Andrew, /usr/proc in Solaris, etc. These all break the model and
introduce various problems in doing so. They are all, imho, mistakes. but they
were all done with some specific goal in mind that was perceived as more
important than the problems they introduced. Generally these were short-term
problems that needed solving at the expense of causing more long-term
problems. In the case of sbin we're introducing a lot of long-term headaches
at the expense of some vague non-problem that nobody complained about before.
> > 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.
I claim there was no point. Nobody has succeeded in defining a point. Putting
/sbin and /usr/sbin permanently in everyone's path would be conceding this, I
agree. This is my favoured solution short of simply abolishing the
directories.
> 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.
There is no difference. Certainly not in any universal sense that could be
effectively decided by us in advance for everyone out there. Trying to will
only be forcing a particular model of usage on our users and making Debian
arbitrarily less useful.
> > 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.
If you want to put everything in section 8 into /sbin or /usr/sbin then I will
insist that /sbin and /usr/sbin should be in the regular path just like
section 8 is in the regular manpath. You will also be violating the language
of the FHS fairly directly. Just because something is primarily used for
administrative function doesn't mean it's not useful for normal users too.
> > 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.
It would make our filesystem layout much more regular. Programs would be
separated only based on features that make partitioning easier rather than
arbitrary value judgements on who will find them useful. It would be less ugly
than having two of every binary directory everywhere for no apparent gain.
We could lower the entropy arbitrarily by dividing all the binaries into
separate subdirectories based on the first letter of their names too. It would
serve no discernible purpose, make it harder for users to find the programs
they're looking for, make it harder to partition effectively etc. But it would
organize for organizations sake. That's what I think /sbin and /usr/sbin are
all about. They're an attempt to organize something in a way orthogonal to the
existing organization with no rationale for why this method serves any useful
purpose for all the added complexity of adding a new, especially vague,
criterion -- program purpose -- for filesystem organization.
--
greg
Reply to: