<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
I've been spending a bit of time looking into libvirt's code and I
believe this is not implemented as Daniel first said.<br>
<br>
The issue is in the qemuOpenFileAs function in
src/qemu/qemu_driver.c which ignores the dynamic ownership flag and
does not set correct ownership on the file. <br>
<br>
The qemuOpenFileAs function is used by other ones as well, so I
wonder if this affects other QEMU features.<br>
<br>
I tried to fix and test it in different use cases and I didn't
notice any side effect, yet I'd like to provide tests as this
function is quite a core one and it's implementation is a bit
confusing (maybe a refactoring would simplify its logic).<br>
Unfortunately the function is not exposed, therefore unittests are a
bit challenging. Higher level tests seem to mock the driver
(src/test/test_driver.c) as well.<br>
<br>
Here's the patch fixing the issue. I set the correct uid and gid
only if the file is being created and dynamic ownership is set.<br>
<br>
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c<br>
index a2cc002..1b47dc6 100644<br>
--- a/src/qemu/qemu_driver.c<br>
+++ b/src/qemu/qemu_driver.c<br>
@@ -2932,6 +2932,11 @@ qemuOpenFileAs(uid_t fallback_uid, gid_t
fallback_gid,<br>
if (path_shared <= 0 || dynamicOwnership)<br>
vfoflags |= VIR_FILE_OPEN_FORCE_OWNER;<br>
<br>
+ if (dynamicOwnership) {<br>
+ uid = fallback_uid;<br>
+ gid = fallback_gid;<br>
+ }<br>
+<br>
if (stat(path, &sb) == 0) {<br>
/* It already exists, we don't want to delete it on
error */<br>
need_unlink = false;<br>
<br>
Please let me know what do you think about it and if we can somehow
include it in the sources. I'd be glad to offer further help if
necessary.<br>
<br>
<div class="moz-cite-prefix">On 29/05/15 16:41, Mathew Moon wrote:<br>
</div>
<blockquote
cite="mid:7422E1B1-5B7B-42ED-8664-4A2432041948@vipaar.com"
type="cite">
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<div>Just a hunch but is the binary that creates the dump suid?
You may want to check the perms on it. Not sure if it is
libvirtd or some other binary.<br>
<br>
Sent from my iPhone</div>
<div><br>
On May 29, 2015, at 3:39 AM, NoxDaFox <<a
moz-do-not-send="true" href="mailto:noxdafox@gmail.com">noxdafox@gmail.com</a>>
wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">2015-05-28 12:04 GMT+03:00 Michal
Privoznik <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:mprivozn@redhat.com" target="_blank">mprivozn@redhat.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0px 0px
0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div class="">
<div class="h5">On 28.05.2015 09:29, NoxDaFox wrote:<br>
> Greetings,<br>
><br>
> I am dumping a guest VM memory for inspection
using the command<br>
> "virDomainCoreDumpWithFormat" and the created
files appear to belong to<br>
> root (both user and group).<br>
><br>
> I have searched around but didn't find any
answer. Is there a way to<br>
> instruct QEMU to create those files under a
different user?<br>
><br>
<br>
</div>
</div>
The coredump should belong to the user:group that the
domain in question<br>
is running under. If (by default) your qemu processes
run under<br>
root:root so will the coredump.<br>
</blockquote>
<div><br>
</div>
<div>I changed default settings but it didn't work. I
can see the qemu processes now belonging to my user
but yet the core dump is root:root. I used to generate
such file with plain QMP 'pmemsave' command and it was
creating it under libvirt-qemu group which was a bit
better. This new command is way more handy but if I
can't sort this issue out I'll need to fallback to the
previous one.<br>
<br>
</div>
<div>I set in /etc/libvirt/qemu.conf the keys<br>
<br>
user = "myuser"<br>
group = "mygroup"<br>
dynamic_ownership = 1<br>
<br>
</div>
<div>And restarted libvirtd.<br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px
0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<br>
Although, I'm wondering if we should not disregard
this and make<br>
coredump be always owned by root:root since a coredump
may contain<br>
sensitive info, e.g. all kinds of cipher keys. We do
that with disk<br>
images, so maybe we should reconsider our politics
with coredumps.<br>
<span class=""><font color="#888888"><br>
Michal<br>
</font></span></blockquote>
</div>
<br>
</div>
<div class="gmail_extra">This would limit the API quite
much. There are use cases in which the need is to dump the
memory for inspection and forcing it to be root would
cripple the design quite a lot. A policy and an expert
SysAdmin is all you need in these cases.<br>
<br>
</div>
<div class="gmail_extra">In my specific case I'm building a
test automation system and I was forced to run everything
as admin or spawn a separate process, with admin rights,
which would reset the correct user:group at every core
dump taken. Quite clumsy!<br>
</div>
</div>
</div>
</blockquote>
<blockquote type="cite">
<div><span>_______________________________________________</span><br>
<span>libvirt-users mailing list</span><br>
<span><a moz-do-not-send="true"
href="mailto:libvirt-users@redhat.com">libvirt-users@redhat.com</a></span><br>
<span><a moz-do-not-send="true"
href="https://www.redhat.com/mailman/listinfo/libvirt-users">https://www.redhat.com/mailman/listinfo/libvirt-users</a></span></div>
</blockquote>
</blockquote>
<br>
</body>
</html>