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.
$ 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):
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 -
[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
$ sudo lvcreate -L 10G -n tmptesting /dev/vg_trick_hdd
Logical volume "tmptesting" created.
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
Try running qemu directly without libvirt using this environment variable:
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