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

[Lennart Poettering]

On Sun, 16.08.15 12:57, Nico Kadel-Garcia (nkadel at gmail.com) wrote:

> > 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.
> 
> 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.

Not really, /sbin was actually introduced originally to contain
statically linked binaries. That's what "s" was supposed to mean,
initially. Linux then later redefined that to mean "system".

> "/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.

Not really, this isn't about "dangerous". This is about "privileges"
on Linux (i.e. "root-only," see FHS). UNIX had a concept of user
priviliges since a long time...

> 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.

Hmm, so you are introducing a new "/.sbin" now? What's the point of
that?  Just use /usr/lib/<package> for private files that are not
supposed to be called by anything else directly, and you are good.

The difference between you and me is that I wan't to clean up the FHS
by simplifying it, and enable new uses while doing so, while you just
want to randomly introduce new directories without actually enabling
anything new...

> All that made clear, I'm going to get a bit persoal. I hope I can keep
> it clear an dpolite enough.
> 
> Lennart,  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.

Hmm? I don't really follow what you are saying. Persistent admin
configuration belongs under /etc, and not under "systemd" or "/run" or
whatever you are saying.

> This includes the sytemd re-arrangement of
> longstanding network configurations such as "/etc/resolv.conf" to a
> symlink to /run, 

I think you are misunderstanding something there. All I am proposing
is that network management software does not make runtime changes to
/etc each time you connect or disconnect to a WLAN. Because /etc is
admin territory, should be considered static and persistent, and
should hence not be manipulated constantly by system software without
explicit request of the admin, during runtime. Or in other words: 
an admin should be able to mount /etc read-only, and the system
should still be able to work (though of course not be able to change
configuration), but I should still be able to connect to WLANs...

Moreover, with everything we proposed there we always said that
/etc/resolv.conf as real file trumps /etc/resolv.conf as
symlink... The symlink is only added if nothing else was in place
there yet.

> the re-allocation of /meda to an ill-defined
> /run/media/username,

I was not really involved in that change (that's udisks). Although I
think it makes a lot of sense, as it fixes security problems with
regards to name clashes of labels between different users.

> 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.

Au contraire. How would that break "decades of stable open source and
free software"? Sure consolehelper needs to be fixed first, but other
than that? Suddenly all binaries are available in both paths. That
means pretty much all scripts that hardcode one or the other path
(maybe because ported over from another distro which sticks some
binaries in a different path of the two than us) will work on our
systems. That certainly *improves* compatibility with external
software, not breaks any.

But anyway, I think we can end the discussion here. You clearly have a
problem with me personally, and I should probably not even have
answered even once...

Lennart

-- 
Lennart Poettering, Red Hat