On Tue, Nov 19, 2013 at 05:53:21PM +0800, Gao feng wrote:
Also after commit 5ff9d8a65ce80efb509ce4e8051394e9ed2cd942 vfs: Lock in place mounts from more privileged users,
unprivileged user has no rights to umount the mounts that inherited from parent mountns.
right now, I have no good idea to fix this problem, we need to do more research. this patch just skip unmounting these mounts for shared root.
BTW, I think when libvirt lxc enables user namespace, the configuation that shares root with host is very rara.
Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com> --- src/lxc/lxc_container.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/lxc/lxc_container.c b/src/lxc/lxc_container.c index 61283e4..8003594 100644 --- a/src/lxc/lxc_container.c +++ b/src/lxc/lxc_container.c @@ -1591,7 +1591,9 @@ static int lxcContainerSetupPivotRoot(virDomainDefPtr vmDef, if (lxcContainerPivotRoot(root) < 0) goto cleanup;
- if (STREQ(root->src, "/") && + /* FIXME: we should find a way to unmount these mounts for container + * even user namespace is enabled. */ + if (STREQ(root->src, "/") && (!vmDef->idmap.nuidmap) && lxcContainerUnmountForSharedRoot(stateDir, vmDef->name) < 0) goto cleanup;
If unmounting fails for these few temporary filesystems, then how is unmount succeeding for everything under /.oldroot after we do the pivot root ? Does the pivot_root() confuse the kernel into thinking stuff under /.oldroot was owned by this process & thus allowed to be unmounted ? Or is it falling back to the MNT_DETACH scenario instead ? Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|