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) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org