Description of problem: I'm a member of the 'disk' group. This means I am able to write to block devices without needing to su to root. However libvirt cannot set the security context on this devices, meaning that tools like virt-builder and virt-resize don't work when the user is non-root and trying to write to a block device. For example: $ virt-builder fedora-19 --output /dev/fedora/tmptesting [ 0.0] Downloading: file:///home/rjones/d/libguestfs/builder/website/fedora-19.xz [ 1.0] Planning how to build this image [ 1.0] Uncompressing [ 29.0] Copying [ 116.0] Opening the new disk virt-builder: libguestfs error: could not create appliance through libvirt. Try using the direct backend to run qemu directly without libvirt, by setting the LIBGUESTFS_BACKEND=direct environment variable.: unable to set security context 'unconfined_u:object_r:svirt_image_t:s0:c328,c758' on '/dev/dm-7': Operation not permitted [code=38 domain=24] Note that the copy operation is successful (which is copying the data to the block device), but libvirt fails as soon as we start up libguestfs on the block device. Version-Release number of selected component (if applicable): libvirt-daemon-qemu-1.1.3-2.fc21.x86_64 How reproducible: 100% Steps to Reproduce: 1. Add yourself to the 'disk' group. 2. Try to write to a block device (success). 3. Try to use libguestfs on a block device (fails). 4. Set LIBGUESTFS_BACKEND=direct and try again (success).
I'm pretty sure this is still an issue with latest libvirt, but can you confirm Rich? Though I think things are working as expected here from libvirt's perspective. Even the the disk is writable by your user, libvirt wants to add the svirt label to ensure that other VMs can't access that disk while your VM is using it. If we can't make that guarantee (because svirt labelling failed, and selinux==enforcing), libvirt should error out. The confusing thing here is that apparently being in the 'disk' group doesn't grant access to change selinux labels. I tried: [crobinso@colepc ~]$ groups crobinso mock devel qa devqa gss-eng-collab crobinso [crobinso@colepc ~]$ chcon -t virt_content_t /dev/sdd1 chcon: failed to change context of ‘/dev/sdd1’ to ‘system_u:object_r:virt_content_t:s0’: Operation not permitted [crobinso@colepc ~]$ su - Password: [root@colepc ~]# chcon -t virt_content_t /dev/sdd1 [root@colepc ~]# restorecon -R -F -v /dev/sdd1 restorecon reset /dev/sdd1 context system_u:object_r:virt_content_t:s0->system_u:object_r:fixed_disk_device_t:s0 From libguestfs's perspective here it likely doesn't care about the svirt protection from access by other VMs, in which case there's ways to disable labeling for specific disk devices via the XML, but that likely comes with some corner cases. But otherwise I think libvirt is correct here. Thoughts?
It still happens for me on Fedora Rawhide with libvirt-1.2.14-2.fc23.x86_64 $ sudo lvcreate -L 10G -n tmptesting /dev/vg_trick_hdd Logical volume "tmptesting" created. $ groups rjones disk wheel dialout $ ll /dev/vg_trick_hdd/tmptesting lrwxrwxrwx. 1 root root 7 Apr 26 09:20 /dev/vg_trick_hdd/tmptesting -> ../dm-4 $ ll /dev/dm-4 brw-rw----. 1 root disk 253, 4 Apr 26 09:20 /dev/dm-4 $ virt-builder fedora-21 --output /dev/dm-4 [ 1.0] Downloading: http://libguestfs.org/download/builder/fedora-21.xz [ 2.0] Planning how to build this image [ 2.0] Uncompressing [ 20.0] Resizing (using virt-resize) to expand the disk to 10.0G virt-resize: error: libguestfs error: could not create appliance through libvirt. Try running qemu directly without libvirt using this environment variable: export LIBGUESTFS_BACKEND=direct Original error from libvirt: unable to set security context 'unconfined_u:object_r:svirt_image_t:s0:c721,c831' on '/dev/dm-4': Operation not permitted [code=38 domain=24]
Then I don't think there's anything for libvirt to fix here. If disk ownership doesn't let an unprivileged user change the selinux label, svirt_t write access to a block device is going to be rejected by selinux policy. So AFAICT your options are either: 1) run the VM without svirt (adding <seclabel type='none' model='selinux'/> to the VM), or 2) use root So closing this bug for libvirt, but maybe you want to repurpose for libguestfs docs change or something