Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1413922 - internal error in libvirt: Cannot unshare mount namespace: Operation not permitted
Summary: internal error in libvirt: Cannot unshare mount namespace: Operation not perm...
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libvirt
Version: unspecified
Hardware: aarch64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Michal Privoznik
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: TRACKER-bugs-affecting-libguestfs
TreeView+ depends on / blocked
 
Reported: 2017-01-17 10:28 UTC by Richard W.M. Jones
Modified: 2017-01-17 12:25 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-01-17 12:25:34 UTC
Embargoed:


Attachments (Terms of Use)
log file (66.04 KB, text/plain)
2017-01-17 10:30 UTC, Richard W.M. Jones
no flags Details
libvirtd.log (306.07 KB, text/plain)
2017-01-17 10:33 UTC, Richard W.M. Jones
no flags Details

Description Richard W.M. Jones 2017-01-17 10:28:16 UTC
Description of problem:

Cannot launch a guest as non-root (ie using qemu:///session)
with libvirt 3.0.0 rc2.

The error is:

libvirt: internal error: Process exited prior to exec: libvirt:  error : Cannot unshare mount namespace: Operation not permitted [code=1 int1=-1]

Version-Release number of selected component (if applicable):

libvirt 3.0.0 rc2

How reproducible:

100%

Steps to Reproduce:
1. Install libvirt 3.0.0 rc2
2. Run libguestfs-test-tool.

Comment 1 Richard W.M. Jones 2017-01-17 10:30:14 UTC
Created attachment 1241660 [details]
log file

Comment 2 Richard W.M. Jones 2017-01-17 10:33:50 UTC
Created attachment 1241662 [details]
libvirtd.log

Log from libvirtd.  Note that it doesn't correspond to the same
session as the client-side log posted in the previous comment.

Comment 3 Richard W.M. Jones 2017-01-17 11:26:14 UTC
I added the following patch/hack to libvirt which fixes it:

diff --git a/src/util/virprocess.c b/src/util/virprocess.c
index f5c7ebb..ef3ed26 100644
--- a/src/util/virprocess.c
+++ b/src/util/virprocess.c
@@ -1155,6 +1155,7 @@ virProcessSetupPrivateMountNS(void)
 {
     int ret = -1;
 
+#if 0
     if (unshare(CLONE_NEWNS) < 0) {
         virReportSystemError(errno, "%s",
                              _("Cannot unshare mount namespace"));
@@ -1166,9 +1167,12 @@ virProcessSetupPrivateMountNS(void)
                              _("Failed to switch root mount into slave mode"));
         goto cleanup;
     }
+#endif
 
     ret = 0;
+#if 0
  cleanup:
+#endif
     return ret;
 }

Comment 4 Michal Privoznik 2017-01-17 11:33:08 UTC
To POST:

https://www.redhat.com/archives/libvir-list/2017-January/msg00719.html

Comment 5 Michal Privoznik 2017-01-17 12:25:34 UTC
I've pushed the patch upstream:

commit d0baf54e53faa544cc41abe8353ee3dce0b0861a
Author:     Michal Privoznik <mprivozn>
AuthorDate: Tue Jan 17 12:15:16 2017 +0100
Commit:     Michal Privoznik <mprivozn>
CommitDate: Tue Jan 17 13:23:56 2017 +0100

    qemu: Actually unshare() iff running as root
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1413922
    
    While all the code that deals with qemu namespaces correctly
    detects whether we are running as root (and turn into NO-OP for
    qemu:///session) the actual unshare() call is not guarded with
    such check. Therefore any attempt to start a domain under
    qemu:///session shall fail as unshare() is reserved for root.
    
    The fix consists of moving unshare() call (for which we have a
    wrapper called virProcessSetupPrivateMountNS) into
    qemuDomainBuildNamespace() where the proper check is performed.
    
    Signed-off-by: Michal Privoznik <mprivozn>
    Tested-by: Richard W.M. Jones <rjones>

v3.0.0-rc2-4-gd0baf54e5


Note You need to log in before you can comment on or make changes to this bug.