Richard Weinberger <richard@xxxxxx> writes: > Am 04.08.2014 18:46, schrieb Eric W. Biederman: >> Richard Weinberger <richard.weinberger@xxxxxxxxx> writes: >> >>> On Sat, Aug 2, 2014 at 12:09 AM, Eric W. Biederman >>> <ebiederm@xxxxxxxxxxxx> wrote: [snip] >> >> Hmm. That problem does sound familiar. >> >> Is the problem oversharing? Is the problem that the mount of /proc in >> the chroot directory is propogating into other mount namespaces that >> don't care? > > /proc is propagating into another mount namespaces that does not care. > This happens because systemd creates for several services a mount namespace and sets > the root tree to MS_SHARED. Unless you are in the primary mount namespace when having this issue it would be good to run mount make-rprivate / before mounting your new /proc. >> If the problem is over propogating I would argue that KIWI needs to >> use a mount namespace instead of a chroot and to tweak the mount >> namespace so the mount of /proc simply does not leak out. >> >> Not that the kernel doesn't need to be fixed but that a design where >> mounts propogate everywhere is a problem in userspace anyway, and it is >> likely going to only need to be a handful of lines of code to fix >> userspace cleanly. While the kernel fix or fixes are going to require a >> bit more time. > > KIWI can bypass the issue by not using a lazy unmount of /proc. > But I fear more applications will need fixing. > While I don't think that it was a wise choice from systemd developers to set > / shared by default I agree that systemd is not the root cause of the problem. > It is the messenger. > > It is just annoying that applications stopped working correctly after upgrading > to systemd. Quite. The deep issue here is actually the design of how mount propogation works. If you want the option of mounts to propogate then you are required to make them shared to start with then after creating a mount namespace if you don't want that sharing you have to do "mount --make-rprivate /". Essentially all of this is documented in Documentation/shared-subtress.txt. Although frankly I have yet to find a case where I really want shared subtreess. Though I have found a few cases where because we have to deal with sharing I using sharing to make it not a pain. Ultimately this means is that in every mount namespace that is created we have to turn off sharing if we don't want it. Which usually we don't because mount namespaces are used when complete sharing is undesirable. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
