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(a)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 :|