[Pkg-systemd-maintainers] Bug#739593: Bug#739593: Bug#739593: closed by Michael Stapelberg <stapelberg at debian.org> (Re: Bug#739593: systemd makes / shared by default)

[Martin Pitt]

Hey all,

Lennart Poettering [2014-02-27 19:50 +0100]:
> > Lennart, we are considering disabling the code in systemd which makes /
> > shared by default so that we follow the kernel default.
> 
> Hmm? Why would you do that?

TBH I found it rather unexpected from systemd to suddenly change that
kernel default, as it has worked the other way for years. Now we are
between a rock and a hard place: Installing systemd breaks existing
stuff that relies on unshared name spaces being private, and patching
it back out breaks applications which rely on the new systemd
behaviour.

> We turned the default from PRIVATE to SHARED on request of the container
> and security guys, since they want that if you mount something from the
> host into a subdir of the container, it should just appear there,
> because that's what most people would most likely expect.

Well, but conversely what scripts/people expected before that script
was that something that you run under "unshare -m" really actually did
what it says on the tin, namely that it really *does* have its private
mount name space. Now it doesn't, and mounts done in that unshared
process affect the system outside of it. I. e. all such programs now
have to be changed to do that "mount --make-rprivate /" dance.

> The kernel default for this is unlikely to change since they argue that
> it breaks compatbility, which I kinda agree with. In systemd however, we
> thought we'd better pick saner defaults.

That has the same net effect though, changing the global default?
systemd and the kernel shouldn't have two different defaults,
otherwise we'll eternally have scripts and programs with different
expectations.

> TL;DR: fix the individual processes locally to disassociate their
> namespaces. Don't tape over it by making all of them disassociate by
> default, breaking those which do not want to disassociate. Because after
> disassociation there is no way back.

I agree that due to this symmetric behaviour of unsharing (which is
really counterintuitive and broken at first sight, but I guess it's
technically difficult to implement in a proper host/guest fashion) we
really shouldn't patch that back in Debian, and just live with the
fallout (and find and fix it over time), as there is no way back as
you explained.

Perhaps as a mitigation /usr/bin/unshare could be fixed to imply
making the unshared namespace private, so that this behaviour
continues as it does before. And of course the kernel should then also
default to the new behaviour, otherwise we have an eternal
inconsistency there and a default which nobody actually uses.

Thanks for your explanations!

Martin

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)