[lxc-devel] [PATCH] [RFC] lxc: don't call pivot_root if / is on a ramfs

[Serge Hallyn]

Quoting Andrew Vagin (avagin at gmail.com):
> On Wed, Oct 08, 2014 at 05:26:03AM +0000, Serge Hallyn wrote:
> > Quoting Serge Hallyn (serge.hallyn at ubuntu.com):
> > > Quoting Andrey Vagin (avagin at openvz.org):
> > > > From: Andrey Vagin <avagin at gmail.com>
> > > > 
> > > > pivot_root can't be called if / is on a ramfs. Currently chroot is
> > > > called before pivot_root. In this case the standard well-known
> > > > 'chroot escape' technique allows to escape a container.
> > > > 
> > > > I think the best way to handle this situation is to make following actions:
> > > > * clean all mounts, which should not be visible in CT
> > > > * move CT's rootfs into /
> > > > * make chroot into /
> > > > 
> > > > I don't have a host, where / is on a ramfs, so I can't test this patch.
> > > > 
> > > > CAUTION: I am not sure that this way is secure.
> > > 
> > > Thanks, Andrey.
> > > 
> > > This is looking ok to me, with the only exception being that (at least
> > > when I test by hand) it looks like you need to bind-mount the root onto
> > > itself before doing the move mount.  (AFAIK we're not doing that before
> > > that in the chroot_into_slave path).
> > > 
> > > We should also make sure to turn all mounts into slave before doing
> > > this, or some hosts will not be happy.
> > 
> > So in the midst of all the other discussion going on, I'm thinking of
> > applying your path with the two needed fixes (bind-mount the root onto
> > itself first, and do the turn-into-slave first)
> > 
> > Please shout if you have any objections or new input.
> 
> Here is an updated patch.

When I run just this as a test program, your chrootbreak2 still works
against it.  When I also chroot first, then the classic chrootbreak
works against it.

If I take your previous version, using MS_MOVE, that'll still be ok
right?

-serge