[lxc-devel] [PATCH] Support MS_SHARED /

[Serge Hallyn]

Quoting Stéphane Graber (stgraber at ubuntu.com):
> On 12/20/2012 06:58 AM, Serge Hallyn wrote:
...
> /proc/mounts in the container will also end up being polluted by all the
> mount points from the host, this in itself doesn't cause any big
> problem, though the container will try (and fail) to unmount all of those.
> Is there anything we can do to improve that situation or is that a side
> effect of MS_SHARED that we can't workaround on our end?

I think it's actually a side effect of pivot-root after chroot.  You
have /orig_root/foo/chroot_root/path/new_pivot/put_old.  Then you
chroot to /orig_root/foo/chroot_root.  When you then pivot to
/path/new_pivot, what ends up in put_old is /orig_root/foo/chroot_root.
I'm actually not sure you can trim the mounts which were under
/orig_root.  We could figure out ones they are by following the chain 
of mount ids in /proc/self/mountinfo, but we can't reach them to umount
them.

It's much like how when you boot a livecd, you see things like
the rootfs on / as well as /cow on /.  You can't reach the rootfs
which is parent of the /cow on / any more, but it's in the mounts
table.

Now I tested, and with a simple setup we can use a much simpler
patch which just does mount("", "/", NULL, MS_SLAVE|MS_REC, 0);
for the whole of chroot_into_slave() (and skips the new umount2()
in start.c).  The container then starts, and its mounts table
is clean.

Where that won't work is in a livecd or any fancy raid setup,
where your process's / has a parent which is MS_SHARED.

Michael, can you show me your /proc/self/mountinfo in a f18
box?

> I didn't spend much time reviewing the code itself, but it applied to my
> local staging tree and built fine, so that's good enough for me :)

Thanks -  TBH the extra mounts are no more wrong than they are in
a livecd, so I don't think it's a big problem.  One we can address
in January.

-serge