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

[Serge Hallyn]

Quoting Serge Hallyn (serge.hallyn at ubuntu.com):
> 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 /
> > 
> > Hi, Andrey,
> > 
> > You're definately right that there was a problem with the
> > pivot_root after chroot.  And with a pure c program I was
> > able to reproduce it on my 14.10 laptop as well, so apparently
> > as you said chroot does something extra in 14.10.
> > 
> > However, as it turns out the kernel source file
> > Documentation/filesystems/ramfs-rootfs-initramfs.txt
> > gives guidance on the right thing to do.  We just need to
> > chdir(tmproot);  mount --move tmproot /;  chroot /;  and then
> > we can pivot_root and cannot subsequently escape.
> > 
> > I've tested http://people.canonical.com/~serge/cis3.c (also appended below)
> > to in fact DTRT.
> > 
> > So I'd prefer to simply add the MS_MOVE before the chroot.
> > 
> > Do you see any problem with doing so?
> 
> We might want to always do this.

Yeah and I think it makes sense, if you look at the pivot_root code.
It grabs the struct path for the current->fs->root;  Then it attach_mnt's
the new root there.  In fact if we chroot to /mnt and bind mount the new
root under /mnt/root, then after the chrootbreak we find the new root
under /mnt/root.

-serge