Description of problem:
This is a variation on bz 507202
Version-Release number of selected component (if applicable):
up2date F11 machine
Steps to Reproduce:
1. setsebool virt_use_nfs true
2. virsh start <some_vm> where VM's disk file lives on NFS directory mounted with default mount options, i.e. with label system_u:object_r:nfs_t:s0
virsh eventually complains
error: Failed to start domain freebsd
error: internal error Domain freebsd didn't show up
VM started successfully
LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin /usr/bin/qemu-kvm -S -M pc -cpu qemu32 -m 512 -smp 1 -name freebsd -uuid fc951cd1-d725-75c8-c2f9-e5cffc8c4c9f -monitor pty -pidfile /var/run/libvirt/qemu//freebsd.pid -boot c -drive file=/data/iso/vm-freebsd.raw,if=ide,index=0,boot=on -net nic,macaddr=00:16:3e:78:a2:47,vlan=0 -net tap,fd=19,script=,vlan=0,ifname=vnet5 -serial none -parallel none -usb -vnc 0.0.0.0:2
libvir: Security Labeling error : SELinuxSetFilecon: unable to set security context 'system_u:object_r:svirt_image_t:s0:c626,c811' on /data/iso/vm-freebsd.raw: Operation not supported.
libvir: QEMU error : internal error Failed to set security label
libvirt shouldn't even attempt to set the SELinux label since (a) the file is on NFS and (b) virt_use_nfs is on
Didn't we fix that with more recent releases, i.e. don't try to relabel
if not needed, I'm pretty sure it should be in 0.7.0
No, that was a different fix. The logic in the fix was 'if setfilecon fails, and the file already has the right label, ignore the error'
What I am talking about here is for NFS mounts, where the only way to get the right label is to specify it as a mount option; that's very clunky. Instead, SELinux offers a virt_use_nfs boolean which should make it possible to use images stored on NFS. Right now, libvirt gets in the way because it tries to setfilecon even for NFS files, which always fails.
The fix I suggest is to not try to setfilecon if a file is on NFS, and report an error only if the virt_use_nfs boolean is off (or just let SELinux report any problems)
I'd been telling people to mount with -o context="system_u:object_r:virt_content_t:s0" but that indeed does suck; the virt_use_nfs boolean is much nicer
There's some more discussion on this in bug #496340
danpb notes that we shouldn't fail to start a guest when we're in permissive mode either
I would agree, just let SELinux report the problem and do not try to setfilecon on file systems that do not support xattrs.
You can now tell this in Rawhide by looking for the seclabel field in /proc/mounts.
if seclabel is not in the /proc/mounts field, libvirt should not try to set the label. Then SELinux will either allow or deny the action.
setfilecon will fail if the mount point does not have this field. (I believe).
Rather than groking /proc/mounts, we can just catch & ignore ENOSYS errno after setfilecon() call.
Sounds good to me. Does the kernel return this if you try to set the label on a files system that was setup with a mount context="CONTEXT"
Created attachment 358174 [details]
email to libvir-list with patch
*** Bug 507202 has been marked as a duplicate of this bug. ***
Here's what got committed:
Included in libvirt-0.7.1-1 (in rawhide/F12 and virt-preview for F11)
*** Bug 516430 has been marked as a duplicate of this bug. ***
bz is against the F11 version, so we still need the fix in F11
libvirt-0.6.2-19.fc11 has been submitted as an update for Fedora 11.
libvirt-0.6.2-19.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing update libvirt'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-10615
libvirt-0.6.2-19.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.