Red Hat Bugzilla – Bug 1045040
/var/lib/libvirt/qemu permissions are wrong
Last modified: 2016-04-10 13:21:40 EDT
drwxr-x---. 6 qemu qemu 4096 Dec 19 12:56 .
Dan thinks we should actually create subdirectories under
here for every guest, with the guest's uid:gid as the owner
of the subdirectory, allowing qemu to run as arbitrary
uid:gid and still access its monitor socket.
Version-Release number of selected component (if applicable):
libvirt 1.1.3 on Fedora 19
Also the same on Fedora 20.
libvirt currently creates the monitor sockets directly in
$ sudo ls -l /var/lib/libvirt/qemu/
srwxr-xr-x. 1 qemu qemu 0 Jan 6 16:00 builder-rhel6.monitor
srwxr-xr-x. 1 qemu qemu 0 Dec 20 22:04 builder-rhel7.monitor
The problem is this doesn't work if we told libvirt to run qemu as
another UID, which is possible (albeit undocumented):
<seclabel model='dac' type='static'> <label>user:group</label> </seclabel>
If you do that you'll find that qemu won't be able to access the
monitor socket in some situations.
To fix this, libvirt should create a subdirectory per guest. The
permissions on /var/lib/libvirt/qemu/ should be relaxed, and the owner
or SELinux label of /var/lib/libvirt/qemu/<guestname> should be set so
qemu can access it.
(I suspect the monitor sockets should really go in /run, but the
same arguments apply)
I agree. for libreswan we run a test suite with libvirt where our own user 'build' creates the vms and every libvirt update my tests start failing and I have to run:
chmod g+w /var/lib/libvirt/qemu/
So at least group qemu write permissions would be nice.
Upstream libvirt does this nowadays:
$ sudo ls /var/lib/libvirt/qemu/
channel domain-9-f23 dump nvram save snapshot
Where domain-9-f23 is used for the monitor socket for running vm name=f23 id=9