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