[Lxc-users] [lxc-devel] pivot root failures when "/" is mounted as "shared"

[Serge Hallyn]

Quoting Michael H. Warfield (mhw at WittsEnd.com):
...
> This was from another threat with the systemd guys.
> 
> On Mon, 2012-10-22 at 16:11 +0200, Lennart Poettering wrote:
> > Note that there are reports that LXC has issues with the fact that
> > newer
> > systemd enables shared mount propagation for all mounts by default
> > (this
> > should actually be beneficial for containers as this ensures that new
> > mounts appear in the containers). LXC when run on such a system fails

MS_SLAVE does this as well.  MS_SHARED means container mounts also
propagate into the host, which is less desirable in most cases.

> > as
> > soon as it tries to use pivot_root(), as that is incompatible with
> > shared mount propagation. The needs fixing in LXC: it should use
> > MS_MOVE
> > or MS_BIND to place the new root dir in / instead. A short term

Actually not quite sure how this would work.  It should be possible
to set up a set of conditions to work around this, but the kernel
checks at do_pivotroot are pretty harsh - mnt->mnt_parent of both
the new root and current root have to be not shared.  So perhaps
we actually first chroot into a dir whose parent is non-shared,
then pivot_root from there?  :)

(Simple chroot in place of pivot_root still does not suffice, not
only because of chroot escapes, but also different results in
/proc/pid/mountinfo and friends)

> > work-around is to simply remount the root tree to private before
> > invoking LXC.
> > 
> > Lennart
> 
> > -- 
> > Lennart Poettering - Red Hat, Inc.
> 
> So there you have a suggested workaround for the shared mount
> propagation problem, which is what you are referring to.
> 
> ITMT...
> 
> Daniel, Serge?
> 
> Any thoughts on those comments vis-a-vis the pivot function and using
> MS_MOVE or MS_BIND instead?  IIRC, we switched to pivot_root() years ago
> to deal with some other issues that were plaguing us.

Yup, see above.  I'm sure it's possible.  But if anyone is going to
sit down and fix it (it might be me, but not right now) I recommend
looking at linux/fs/namespace.c before blindly poking.

-serge