Re: /sbin link to /bin?
> If the Hurd philosophy wants to ignore /usr, why not to
> ignore /sbin, too.
I think they are really entirely separate issues. (That doesn't mean that
keeping /sbin is therefore inherently right, but it means that the
rationale for the /usr -> / symlink does not say anything about the /sbin
issue.)
The / vs /usr distinction is purely about storage and low-level issues that
not only does a non-administrator user never think about at all, but that
even the administrator of the system doesn't usually think about in normal
operation (i.e. you think about how to set it up when installing the system
and you think about what it means when you are rebooting and fsck'ing and
restoring backups and so forth, but it's usually irrelevant to life once
the system is up multiuser). Thus we have concluded that having the
distinction visible in normal use (i.e. /usr/bin != /bin) is more hassle
than benefit to anyone, and intend to instead provide (eventually) better
ways to accomplish the useful aspect of the distinction, i.e. let the
administrator specify where things are stored and what gets fsck'd when,
etc., in a way conveniently independent from the names by which those
things are accessed in normal use.
Conversely, the /bin vs /sbin distinction is purely about avoiding
inconvenience and/or confusion for the normal user. The sole thing
accomplished by putting some things in /sbin rather than /bin is that if
you don't put /sbin in your path, you won't see those things. I myself,
probably like most people on this list, rarely notice the distinction since
I do have /sbin (and /usr/sbin, on non-Hurd systems) in my path. But the
idea is that the average user won't have /sbin or /usr/sbin in their path,
and so the programs in those directories can have simple names for the
convenience of those who do use them, without an average user either
accidentally running one because it has a simple name they confused with
something else, or getting a lot of confusing possibilities in a command
completion list.
> AFAIK /sbin is used for binaries intended for the super-user, and under
> Hurd, using translators, the distiction root-normal_user seems not to be
> the same of other unix implementations.
I am not sure exactly what you are referring to, but I will guess. In the
Hurd any user can set up translators (filesystems) and control them, which
you might think of in the context of traditional Unix systems has a
"superuser" kind of thing to do. The Hurd programs for these things are
settrans and fsysopts (among others), which are akin to Unix mount. We put
these programs in /bin, while Unix systems put mount in /sbin.
But note that on most current Unix systems (if things are configured
appropriately), normal users often can use mount (for removable media
devices and such). The reason for putting mount in /sbin is perhaps
historical (it was certainly the case when /sbin was originally split out
of /bin that /sbin/mount was something only root could run), but I like to
think instead that it fits my definition of the intended distinction: mount
is a hairy systems command, and a naive user would be confused by trying to
use it or running it accidentally. Conversely, in the Hurd we intend using
translators to become a very common thing that a relatively naive user
might know about and want to use frequently--so settrans, fsysopts, et al
are in /bin.
The things that we do put in /sbin on the Hurd are for the same reason: we
expect that the average user will not use them and might be confused by
encountering them. For example, mkfs and fsck and so forth are in /sbin.
Anyone can use these, on a file or on a device they have permissions for.
It's not that we expect only root to use these, but that we expect anyone
who wanted to use them to probably know enough about the system to be root
(or at least enough more than the average user that they can handle putting
/sbin in their path). This is the same on Unix and Linux as on the Hurd.
There are many other programs in /sbin (or /usr/sbin) on Unix/Linux that
any non-root user might well run. I don't think there is any fundamental
distinction here between the Hurd and other systems.
Nor is there any great distinction (as yet) for most purposes to the way
the Hurd treats privilege vis a vis root and such compared to Unix systems.
It is true that we have more flexible underlying mechanisms for choosing
what criteria to apply to control privilege for any particular thing, and
we have a more flexible higher-level protocol for acquiring, holding and
presenting privilege (multiple uids). But the servers we have now all
mostly use the traditional root privilege concept. Many things are
controlled by the permissions set on individual file nodes (devices,
whatever), which is also true on Unix and Linux.
> Leaving /sbin would make the filesystem structure simpler, too.
Perhaps. On the other hand, it would make the contents of /bin more
complex as a whole. The filesystem structure is unavoidably going to be
complex, but not everyone has to think about all of it. /bin is the
fundamental interface for all command-line users, so everyone has to see it.
Reply to: