[lxc-devel] [PATCH] Support MS_SHARED /

[Serge Hallyn]

Quoting Michael H. Warfield (mhw at WittsEnd.com):
> On Wed, 2013-01-16 at 16:46 -0600, Serge Hallyn wrote:
> > Quoting Michael H. Warfield (mhw at WittsEnd.com):
> > > Serge,
> > > 
> > > Revisiting an earlier remark...
> > ...
> > > > 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.
> > > 
> > > Were you still looking at this?  Currently, with the MS_SHARED patch
> > 
> > No, I haven't been.
> > 
> > > work in 0.9.0, the mount table is pretty ugly and running "df" in a
> > > container is really ugly...
> > > 
> > 
> > ...
> > 
> > > > 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.
> > > 
> > > How bad is this breakage in regards to that then?
> 
> > pivot_root would simply fail.
> 
> > Likewise, the case where / is actually type 'rootfs', which is
> > not MS_USER and therefore can't be pivot_root()d from would
> > fail.
> 
> > There is something else we could try.  Before we chroot() into
> > our custom MS_SLAVE /, we could fork a child.  That child sticks
> > around, waits for a signal saying the pivot_root+umounts are
> > done, then it looks through /proc/self/mounts and unmounts
> > anything which is not under '/root/'.
> 
> > I think that might really work best.
> 
> That certainly sounds like it might be worth a shot.  If you could get
> me a patch, I could test.  Beginning in a week I'm going to be out of
> pocket for a couple of weeks with access severely limited to my test
> servers, though.

Let's remember this for when you get back then - I won't have time (that
is, be able to justify moving other things) before then.

If someone else wants to write the patch, I think it'll be a fun one to
write.

-serge