Re: /etc/profile should include sbin in PATH
Greg Stark <gsstark@mit.edu> wrote:
> 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.
The burden of proof on me? I'm defending the status quo. You are the
one proposing a change that will make us different from other Linux
distributions (assuming that they follow the FHS or FSSTND), GNU coding
practices, and BSD practices. As far as I know (and please correct me
if I'm wrong), the other Linux distributions and *BSDs all contain /sbin
and /usr/sbin with such system binaries, and they do not include these
directories in the default path for ordinary users. (I just checked on
an OpenBSD machine, and it has its version of ifconfig in /sbin.)
There already exist standards documents explaining the rationale
behind these directories. I know that you do not find their arguments
convincing, but I'm afraid that if you are going to convince us to
disregard these standards and ignore the recommended way of doing
things, then you need a better argument. The only thing that you've
demonstrated to me is that you have a pet peeve against sbin.
I have expressed my feelings that this "awkwardness" and "pain" that you
describe is hardly any trouble at all! My goodness! You're complaining
because someone might have to fiddle with his own PATH environment
variable. I hardly find this to be "painful" and "insulting."
> 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.
That's fine. I'm sure your friends have no trouble changing their paths
to include the sbin directories, or setting up an alias or symbolic link
for ifconfig.
Programmers will write their own programs, and therefore, will likely
want to run executable files in the current directory. Unfortunately
for them, however, the default path does not contain ".", the current
directory. And since it is awkward and painful to place a "./" in front
of their programs every time they want to test them, they usually modify
their path to include ".". Surely, you do not want to suggest that all
users' paths contain "." by default, do you?
> > [Greg Stark <gsstark@mit.edu> wrote:]
> >
> > > 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.
>
> [Brian Mays <brian@debian.org> wrote:]
>
> > 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.
Huh? Did I miss something? How does that follow?
> 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.
I think that there is a misunderstanding here. You stated that the
programs that can be usefully run as an ordinary user depends on such
stuff as file permissions on the current system. I replied that if the
local administrator changes these permissions or alters the system in
such a non-standard way, then he can use symlinks to link binaries from
the sbin directories to /usr/local/bin. All that I am advocating is
that Debian place its binaries according to its default policy (file
permissions, etc.).
> > > 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 Brian May (not to be confused with me, although we have very similar
names) has pointed out, our own MH packages use /usr/bin/mh.
> [Brian Mays <brian@debian.org> wrote:]
>
> > 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 administer, 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.
There is no difference between administrative work and ordinary work?
Then why do I need a user account? Why shouldn't I just do EVERYTHING
as root?
Besides, we are not forcing anything on anybody. If the programs in the
sbin directories were made executable *only* by root, then I would agree
that things need to change, but that is not the case. Any user can
add the sbin directories to his path. It is also easy to add an alias
ifconfig=/sbin/ifconfig. Why do you consider this to be so difficult?
[ Greg Stark's arguments against /sbin and /usr/sbin omitted. ]
I understand that you do not like /sbin and /usr/sbin (along with
several other directories in our filesystem), however, if you felt
so strongly on this topic, you should have argued your case with the
Filesystem Hierarchy Standard Group. As it stands, they decided, for
whatever reasons, that such directories are useful, and now we must
decide whether we will go along with their recommendations or whether we
will go our own way and be (stubbornly) non-standard.
Personally, I find your arguments about the poor, suffering
programmers who must search aimlessly for ifconfig and traceroute to
be unconvincing. They address an annoyance that is easily fixed and
which I'm sure most people on this list could care less about. They are
hardly a reason to abandon the recommend standard and common practice.
Brian
Reply to: