<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<font size="+1">Hi Erik,<br>
<br>
Just to let you know that the error I reported in one of my
replies was<br>
being caused by one change I forgot to undo. This error here:<br>
<br>
</font><br>
<font size="+1">error : virQEMUCapsNewForBinaryInternal:4687 :
internal error: Failed to
<br>
probe QEMU binary with
<br>
QMP: libvirt: error : prctl failed to enable 'dac_override' in
the AMBIENT
<br>
set:
<br>
Operation not permitted<br>
<br>
<br>
was happening because I have commented out this line inside<br>
qemu_capabilities.c:<br>
<br>
--- a/src/qemu/qemu_capabilities.c<br>
+++ b/src/qemu/qemu_capabilities.c<br>
@@ -4519,7 +4519,7 @@
virQEMUCapsInitQMPCommandRun(virQEMUCapsInitQMPCommandPtr cmd,<br>
"-daemonize",<br>
NULL);<br>
virCommandAddEnvPassCommon(cmd->cmd);<br>
- virCommandClearCaps(cmd->cmd);<br>
+ // virCommandClearCaps(cmd->cmd);<br>
<br>
#if WITH_CAPNG<br>
/* QEMU might run into permission issues, e.g. /dev/sev
(0600), override<br>
<br>
<br>
Thus there is no need to move the </font><font size="+1">PR_CAP_AMBIENT
around to prevent the<br>
error message. Sorry for any alarms I might have raised there.<br>
<br>
<br>
I'm still experiencing the issue with IPC_LOCK inside the guest
though. I'll update<br>
here when I have concrete findings about it.<br>
<br>
<br>
Thanks,<br>
<br>
DHB<br>
<br>
</font>
<div class="moz-cite-prefix">On 2/4/19 4:26 PM, Daniel Henrique
Barboza wrote:<br>
</div>
<blockquote type="cite"
cite="mid:ba6e9e68-ebf4-cb90-6d43-2943587703b5@gmail.com">Hey
Erik,
<br>
<br>
<br>
On 2/4/19 8:11 AM, Erik Skultety wrote:
<br>
<blockquote type="cite">On Fri, Feb 01, 2019 at 07:40:36PM -0200,
Daniel Henrique Barboza wrote:
<br>
<blockquote type="cite">Update: I've figured it out.
<br>
<br>
The bug here was that, even running as root, I was getting
errors like:
<br>
<br>
error : virQEMUCapsNewForBinaryInternal:4687 : internal error:
Failed to
<br>
probe QEMU binary with
<br>
QMP: libvirt: error : prctl failed to enable 'dac_override'
in the AMBIENT
<br>
set:
<br>
Operation not permitted
<br>
</blockquote>
Being responsible for the latest changes wrt to capabilities,
this error itself
<br>
is very strange because the prctl man page says the following
about EPERM errno:
<br>
<br>
"option is PR_CAP_AMBIENT and arg2 is PR_CAP_AMBIENT_RAISE, but
either the
<br>
capability specified in arg3 is not present in the process's
permitted and
<br>
inheritable capability sets, or the PR_CAP_AMBIENT_LOWER
securebit has been
<br>
set."
<br>
<br>
So I'm wondering how can that be since that prctl call happens
after we applied
<br>
the capabilities we want with capng_apply. Just out of
curiosity, what happens
<br>
if you move the whole PR_CAP_AMBIENT at the very end of
virSetUIDGIDWithCaps
<br>
function? Does it change anything?
<br>
</blockquote>
<br>
Moving the code as you suggested got rid of the internal error:
<br>
<br>
<br>
--- a/src/util/virutil.c
<br>
+++ b/src/util/virutil.c
<br>
@@ -1587,27 +1587,6 @@ virSetUIDGIDWithCaps(uid_t uid, gid_t gid,
gid_t *groups, int ngroups,
<br>
goto cleanup;
<br>
}
<br>
<br>
-# ifdef PR_CAP_AMBIENT
<br>
- /* we couldn't do this in the loop earlier above, because the
capabilities
<br>
- * were not applied yet, since in order to add a capability
into the AMBIENT
<br>
- * set, it has to be present in both the PERMITTED and
INHERITABLE sets
<br>
- * (capabilities(7))
<br>
- */
<br>
- for (i = 0; i <= CAP_LAST_CAP; i++) {
<br>
- capstr = capng_capability_to_name(i);
<br>
-
<br>
- if (capBits & (1ULL << i)) {
<br>
- if (prctl(PR_CAP_AMBIENT, PR_CAP_AMBIENT_RAISE, i, 0,
0) < 0) {
<br>
- virReportSystemError(errno,
<br>
- _("prctl failed to enable
'%s' in the "
<br>
- "AMBIENT set"),
<br>
- capstr);
<br>
- goto cleanup;
<br>
- }
<br>
- }
<br>
- }
<br>
-# endif
<br>
-
<br>
/* Set bounding set while we have CAP_SETPCAP. Unfortunately
we cannot
<br>
* do this if we failed to get the capability above, so
ignore the
<br>
* return value.
<br>
@@ -1630,6 +1609,27 @@ virSetUIDGIDWithCaps(uid_t uid, gid_t gid,
gid_t *groups, int ngroups,
<br>
goto cleanup;
<br>
}
<br>
<br>
+# ifdef PR_CAP_AMBIENT
<br>
+ /* we couldn't do this in the loop earlier above, because the
capabilities
<br>
+ * were not applied yet, since in order to add a capability
into the AMBIENT
<br>
+ * set, it has to be present in both the PERMITTED and
INHERITABLE sets
<br>
+ * (capabilities(7))
<br>
+ */
<br>
+ for (i = 0; i <= CAP_LAST_CAP; i++) {
<br>
+ capstr = capng_capability_to_name(i);
<br>
+
<br>
+ if (capBits & (1ULL << i)) {
<br>
+ if (prctl(PR_CAP_AMBIENT, PR_CAP_AMBIENT_RAISE, i, 0,
0) < 0) {
<br>
+ virReportSystemError(errno,
<br>
+ _("prctl failed to enable
'%s' in the "
<br>
+ "AMBIENT set"),
<br>
+ capstr);
<br>
+ goto cleanup;
<br>
+ }
<br>
+ }
<br>
+ }
<br>
+# endif
<br>
+
<br>
<br>
<br>
<br>
<br>
However, this code still doesn't add IPC_LOCK as capability:
<br>
<br>
<br>
index 0d58f1ee57..f4b46abc08 100644
<br>
--- a/src/util/virutil.c
<br>
+++ b/src/util/virutil.c
<br>
+++ b/src/qemu/qemu_capabilities.c
<br>
@@ -4525,6 +4525,9 @@
virQEMUCapsInitQMPCommandRun(virQEMUCapsInitQMPCommandPtr cmd,
<br>
/* QEMU might run into permission issues, e.g. /dev/sev
(0600), override
<br>
* them just for the purpose of probing */
<br>
virCommandAllowCap(cmd->cmd, CAP_DAC_OVERRIDE);
<br>
+ virCommandAllowCap(cmd->cmd, CAP_IPC_LOCK);
<br>
+ virCommandAllowCap(cmd->cmd, CAP_IPC_OWNER);
<br>
+
<br>
#endif
<br>
<br>
<br>
<br>
So I am not sure if my mod above is wrong or your suggestion of
moving the
<br>
PR_CAP_AMBIENT code made the warning go away but isn't setting the
capabilities
<br>
at all. I'll investigate it more.
<br>
<br>
<br>
<br>
DHB
<br>
<br>
<br>
<blockquote type="cite">
<br>
Thanks,
<br>
Erik
<br>
<br>
<blockquote type="cite">The reason is that the host has
libcap-ng installed. ./configure uses it if
<br>
available,
<br>
setting WITH_CAPNG in the code. I am unsure if this has
something to do with
<br>
the libcap-ng configuration in this system I'm using or if
there is
<br>
something
<br>
missing in the Libvirt code, but the spawned QEMU process
isn't inheriting
<br>
the
<br>
capabilities it should have.
<br>
<br>
Disabling support of this lib with "--with-capng=no" in
autogen.sh and
<br>
rebuilding Libvirt fixed the problem. I was even able to see
more NUMA
<br>
nodes than I was before using the system libvirt (which is the
original
<br>
bug I am/was investigating).
<br>
<br>
<br>
Thanks!
<br>
<br>
<br>
<br>
<br>
<br>
On 2/1/19 4:04 PM, Daniel Henrique Barboza wrote:
<br>
<blockquote type="cite">Hi,
<br>
<br>
I'm facing a strange behavior when running Libvirt from
source code,
<br>
latest upstream, on an Ubuntu 18.04.1 LTS Power 9 server. My
QEMU
<br>
guest - which is using VFIO and GPU passthrough - breaks on
boot when
<br>
trying to allocate a DMA window inside KVM.
<br>
<br>
Debugging the code, I've found out that the problem is
related to the
<br>
process
<br>
not having CAP_IPC_LOCK - at least from the host kernel
perspective.
<br>
<br>
This is strange because:
<br>
<br>
- the same VM running directly from QEMU command line works
<br>
- the same VM running in the system Libvirt (v4.0.0, Ubuntu
version)
<br>
also works
<br>
<br>
What am I missing? My understanding on Linux process is that
a process
<br>
running as root should inherit the same capabilities of the
user, which
<br>
includes
<br>
CAP_IPC_LOCK. Running Libvirt from source code should grant
ipc_lock
<br>
to it ... right?
<br>
<br>
<br>
<br>
Any help is appreciated. I can provide more details (VM XML
for example)
<br>
if necessary.
<br>
<br>
<br>
Thanks!
<br>
</blockquote>
--
<br>
libvir-list mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:libvir-list@redhat.com">libvir-list@redhat.com</a>
<br>
<a class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/libvir-list">https://www.redhat.com/mailman/listinfo/libvir-list</a>
<br>
</blockquote>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>