Thanks Richard,
I agree with you. Do you have any suggestion how this should be
implemented? My first impression is that the virSecurityManager*
internal API should be extended to support that.
The current code in qemu_process.c already uses
virSecurityManagerSetDaemonSocketLabel() and
virSecurityManagerClearSocketLabel() to set the correct SELinux context.
However they can't be used to add similar functionality to DAC driver.
Regards,
Marcelo
On Thu, Jan 09, 2014 at 04:57:30PM +0000, Richard W.M. Jones wrote:
On Thu, Jan 09, 2014 at 02:12:20PM -0200, Marcelo Cerri wrote:
> Hi,
>
> Any directions regarding which is the best approach to correct the bug
> reported in
https://bugzilla.redhat.com/show_bug.cgi?id=1045040 ?
[This is a copy of the comment I added to that bug]
libvirt currently creates the monitor sockets directly in
/var/lib/libvirt/qemu/ eg:
$ sudo ls -l /var/lib/libvirt/qemu/
total 16
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
[etc]
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)
Rich.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v