UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)

Lennart Poettering mzerqung at 0pointer.de
Sun Oct 30 22:02:20 UTC 2011


On Mon, 24.10.11 13:05, Chris Adams (cmadams at hiwaay.net) wrote:

Here's an attempt to summarize the rationale for merging /bin, /sbin,
/usr/sbin into /usr/bin with different words collecting the various points
raised:

a) the split between sbin and bin requires psychic powers from
   upstream developers:

   The simple fact is that moving binaries between these dirs is really
   hard, and thus developers in theory would need to know at the time
   they first introduce a binary whether it *ever* might ever make sense to
   invoke it as unprivileged user (because in that case the binary
   belongs in /bin, not /sbin). History shows that more often than
   not developers have placed their stuff in the wrong directory, see
   /sbin/arp, /sbin/ifconfig, /usr/sbin/httpd and then there is no smart
   way to fix things anymore since changing paths means breaking all hardcoded
   scripts. And hardcoding paths in scripts is actually something we
   encourage due to perfomance reasons. The net effect is that many
   upstream developers unconditionally place their stuff in bin, and
   never consider sbin at all which undermines the purpose of sbin
   entirely (i.e. in systemd we do not stick a single binary in sbin,
   since we cannot be sure for any of its tools that it will never
   ever be useful for non-root users. and systemd is as low-level,
   system-specific it can get).

b) The original definition of /sbin is fully obsolete (i.e. the "s" in
   sbin stood originally for "static" binaries)

c) /bin vs. /sbin is not about security, never has been. Doing this
   would be security by obscurity, and pretty stupid, too.

d) splitting /bin off /sbin is purely and only relevant for $PATH, and
   $PATH is purely and only something to ease access to the tools in it
   for shell users. The emphasis here is on "ease". It is not a way to
   make it harder for users to access some tools. Or in other words: if
   your intention is to hide certain tools from the user in order not to
   confuse him, then there are much better places for that: the
   documentation could document them in a separate section or so. I
   don't think it makes any sense at all trying to educate the user by
   playing games with what he can see if he presses TAB in the shell. On
   top of that users who use the shell are the ones who react allergic
   to this kind of attempts of forced education anyway. So just drop
   this nonsense.

e) the split between sbin/ and /bin is effectively made redundant already,
   since both are listed in the $PATH of all users already since a
   couple of Fedora versions. And due to d) the split hence has no
   reason to exist, at all.

f) splitting things up complicates stuff. If you want to keep things
   separate you really need a good reason for that. We should always
   focus on simplifiying things. And merging things into /usr does just
   that: it drastically simplifies the complexities we have collected
   over 30+ years of Unix heritage.

g) given that some distros place certain binaries in other places than
   others, merging the dirs has the big benefit that the four paths are
   equivalent and scripts from other distros work on ours, regardless
   where the other distros place their stuff

h) the split between /usr and / was mostly about early boot
   initialization: i.e. a minimal system was available in / which was
   just good enough to find the full OS stuff in /usr. But that hasn't
   worked in ages, and the discussion for split off /usr is over and the
   install option got removed from anaconda (though you can still
   install things like that by hand if you really want to shoot yourself
   in the foot)

   http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken

i) The separation between minimal boot system in / and full system in
   /usr is obsoleted by initrd in a way: the new minimal boot system is
   the initrd. Stacking multiple levels of "minimal boot system", one
   after the other is a stupid game. So let's stick to the one we really
   need which is initrd, and forget about the one that we don't need
   anymore, and is broken since ages.

j) having all static, distribution-provided, sharable OS stuff in a single dir
   in /usr simplifies read-only setups drastically. I think we should
   ensure that having the OS itself read-only is something that works
   right-away without having to enable special modes that do this which
   involves a ton of less-than-beautiful hacks. Being able to make the
   libc and other core libraries fully read-only without also having to
   make /etc read-only and without having to add a junkload of r/o bind
   mounts is highly desirable.

k) having all static, distro-specific, sharable OS in a single dir
   makes snapshots of the OS independetly of its state and configuration
   truly atomic. In a btrfs world doing 5 snapshots of /lib, /lib64,
   /bin, /sbin and /usr instead of just one is not atomic, and hence
   racy, and ugly, and boooh!

l) having a clear separation between sharable data
   (i.e. /usr)  and everything else is highly desirable for
   network setups, and for container setups.

m) Upstream build scripts can be vastly simplified, since autoconf does not
   know about the separation between / and /usr (and never did), and
   getting autoconf right in the context of the split traditional is immensly
   difficult, with the effect that almost nobody got it right. And we
   have quite a few components who never even tried (i think Plymouth?)

n) Harald has done the work for testing and showed that merging the dirs
   works, and that the path towards it is pretty clear and managable,
   and that it creates no major issues on the way.

o) we have somebody who wants to do the work.

And that's all I could come up with for now. Putting this together I am
all in favour of this simplification. As a developer it would make
things a lot simpler for me. Packagers will have things much simpler
(after the transition) too, and finally administrators have the major
benefits of the atomicity of the btrfs snapshotting, and for network and
especially container setups. And those three are absolute killer
features in my eyes.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.


More information about the devel mailing list