Re: /etc/profile should include sbin in PATH

[Greg Stark <gsstark@mit.edu>]

tb@MIT.EDU (Thomas Bushnell, BSG) writes:

> The GNU project adopted /sbin because ordinary users should not be
> burdened with executables that they *cannot* run usefully.  (Which is
> in fact the same reason that they are in /etc or /sbin in BSD.)

I would be somewhat happier if that were the language in the FHS or Debian
policy. However, there are many programs in sbin that are useful for ordinary
users including the two explicitly listed in the FSSTND, traceroute and
ifconfig.

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"

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.

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.

The only programs I would be willing to put in an sbin would be system
daemons, and <package>-configure scripts or similar configuration scripts.
Even then there are lots of cases that will overlap, like stunnel, but at
least the criteria will be clear.

> It sounds to me that Greg Stark is not familiar with this language,
> and he should be asking for more discipline about taking "only
> generally useful to system administrators" with more strictness than
> it is generally given.

I was only familiar with the FSSTND, which was even more vague than that. 

I guess I propose that either of two things happen:

1) /sbin and /usr/sbin are put into everyone's path. 

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.

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. 

Obviously the path of least resistance at least for potato is (1).

-- 
greg