Same comand names in /usr/bin and /usr/sbin

[Nico Kadel-Garcia]

On Sun, Aug 16, 2015 at 8:03 AM, Lennart Poettering
<mzerqung at 0pointer.de> wrote:
> On Fri, 14.08.15 17:58, Matthew Miller (mattdm at fedoraproject.org) wrote:
>
>> On Fri, Aug 14, 2015 at 07:24:16PM +0200, Lennart Poettering wrote:
>> > Given that sbin is in $PATH for unprivileged users too the seperation
>> > is really pointless, since it's now only the $PATH order which makes
>> > this not explode.
>>
>> Yeah; I have a halfhearted wish to rationalize what goes in sbin and
>> what goes in bin. One approach would be to make sbin be commands that
>> wouldn't normally be even in privileged users' $PATH — daemons and so
>> on that should be launched by init. (Having crond in my path is just
>> polluting the namespace.) But all of that is a lot of churn for
>> something that's... not usually a problem.
>
> Also, that ship has sailed a long time ago, when we added sbin to very
> user's $PATH, not just root's...
>
> There's the general problem that things which were initially intended
> to be run only by root often are opened up later for unprivileged
> clients, and if that happens you'd have to move the file from bin/ to
> sbin/, but that breaks API, since the paths of many binaries are kinda
> assumed to be API by many scripts. That then resulted in people
> placing compat symlinks, so that /usr/sbin/tracepath for example
> became a symlink to /usr/bin/tracepath so that both paths are
> available.

This is not such a problem if the files are identical. For "mock",
"authconfig", and others trhat I personally mentioned, they are
distinct binaries. I'd prefer to see that be discarded. If one is a
binary that sommons the other with parameters, *rename* the target.

> In general: encoding privilige policy into the API through binary
> paths is a really bad idea, as policy shouldn't be considered strict
> API (or to be more precise: it should be allowed to open up policy --
> while of course not necessarily to close it down later on), but paths
> are.
>
> Hence: we should say goodbye to the concept of separate bin/sbin, we
> kinda did already by adding both to $PATH for all users, but we should
> work on making this go away in the FS hierachy too, and replace sbin
> by a symlink.
>
> Lennart

Oh, my. I'm afraid I'm going to have to backfilll some history for
reletavily new Linux developers.

that unless you study some history, you won't understand this stuff.
The original UNIX bootstrap tools lived in "/etc", namely the "dump"
and "restore" tools and very little else. Later, as Linux was created,
the "/" partition contained "/bin" and "/sbin", barely enough tools to
run limited scripting and a other tools to be able to do the basic OS
or restoration bootstrapping, tools that wouldn't fit in the old
"/etc" hardcoded and limited disk space anymore.

"/usr" was deployed later in the bootstrapping processes, and included
far more site specific components.
It included more than the most basic and universal bootstrapping
toolkits. Both in "/sbin" on "/", and with "/usr/sbin" on "/usr" those
tools were segregated because they were "dangerous* for ordinary users
to play with, and potentially to confuse themselves and screw up the
machine. The tools were still available, but they required specific
selection to use.

It's a basic violation of the ordinary segregation between "/bin" as
ordinary user tools" and "/sbin" as sysadmin tools to start mixing
them, and much more confusing to have the same program name in both.
And it's frankly easy to avoid. "mock", for example, should rename
"/.sbin/mock" to something else to avoid command line confusion.

All that made clear, I'm going to get a bit persoal. I hope I can keep
it clear an dpolite enough.

Leonart,  I'm afraid that it's very difficult to trust your opinion on
anything involving ordinary filesystem layout.  Your work with systemd
makes it clear that you wish to discard much, if not all, of the
existing configuration layout and File System Hierarchy to put it all
under systemd and /run. This includes the sytemd re-arrangement of
longstanding network configurations such as "/etc/resolv.conf" to a
symlink to /run, the re-allocation of /meda to an ill-defined
/run/media/username,

I'm not saying these desires are not understandable, or evil. But it's
very clear that you have other practices and goals in mind than a
great deal of the existing Linux and UNIX community. And your
suggested policies are often aimed at those broader goals, not aimed
at solving the particular individual problem. Your comments above are
one such example. *No one else* suggested discarding /sbin. Doing so
will break decades of stable open source and free software.