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

[Andrey Wagin]

2014-10-08 18:54 GMT+04:00 Serge Hallyn <serge.hallyn at ubuntu.com>:
> 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.

chrootbreak2 works for my previous version too. It was a reason, why I
decided to fix the kernel.

> When I also chroot first, then the classic chrootbreak
> works against it.

I don't understand this.

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

Yes, that will.

The second version contains a few additional comments and it doesn't
use a file descriptor to chroot in a CT root.

>
> -serge