Description of problem: This is a variation on bz 507202 Version-Release number of selected component (if applicable): libvirt-0.6.2-13.fc11.x86_64 up2date F11 machine How reproducible: 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 Actual results: virsh eventually complains error: Failed to start domain freebsd error: internal error Domain freebsd didn't show up Expected results: VM started successfully Additional info: In /var/log/libvirt/freebsd.log: 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 Daniel
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: http://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=777fc2e9d6
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. http://admin.fedoraproject.org/updates/libvirt-0.6.2-19.fc11
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.