On 11/19/2013 11:00 PM, Daniel P. Berrange wrote:
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 ?
./oldroot is mounted in container, so container has rights to umount it, but for sub mounts under ./oldroot, container has no rights to umount them, so it falls back to MNT_DETACH scenario. hmm, So I think for the [PATCH 1/2], use MS_BIND instead of MS_MOVE may be a simple way, since even we move the /dev /dev/pts on host side, the unmount ./oldroot will fall back to MNT_DETACH scenario too.