Hide Forgot
Description of problem: I have a xen domain configured with an LVM snapshot as it's disk. When I try to start the domain from libvirt or xm, I get an error: "Error: Disk isn't accessible" When I switch to permissive mode, the domain starts successfully. The messages from audit.log are: type=SYSCALL msg=audit(1318518578.324:133): arch=c000003e syscall=21 success=yes exit=0 a0=7f20dc05f020 a1=4 a2=7f2115c2e4c8 a3=7f21159b6770 items=0 ppid=1 pid=3498 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="xend" exe="/usr/bin/python" subj=system_u:system_r:xend_t:s0 key=(null) type=AVC msg=audit(1318518578.580:134): avc: denied { open } for pid=3499 comm="pygrub" name="dm-8" dev=devtmpfs ino=10346 scontext=system_u:system_r:xend_t:s0 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file type=SYSCALL msg=audit(1318518578.580:134): arch=c000003e syscall=2 success=yes exit=4 a0=2253a40 a1=0 a2=1ff a3=7fc3fdffe770 items=0 ppid=1225 pid=3499 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts7 ses=4294967295 comm="pygrub" exe="/usr/bin/python" subj=system_u:system_r:xend_t:s0 key=(null) Version-Release number of selected component (if applicable): selinux-policy-3.10.0-38 How reproducible: every time Steps to Reproduce: 1. start Xen domain Actual results: "Error: Disk isn't accessible" Expected results: Start domain Additional info:
This looks like a libvirt error since it is supposed to change the label on the fixed disk.
*** Bug 747662 has been marked as a duplicate of this bug. ***
Anyone working on this bug?
Pasi: I don't think so... There's a known workaround, and given what it deals with it's easy to assume that whoever runs into the error would be able to work around it. I'm just wondering if there's a fix for it - by default, virt-manager (and I'm guessing libvirt) create disk images for VMs. When I created a LVM-backed VM, I manually ran lvcreate, which doesn't label the resulting disk properly for use by xend. I don't think libvirt can solve this by itself unless it can relabel stuff, which I don't think it can - otherwise libvirt (and other programs) could subvert SELinux. I think a note of which label to use could go into the Xen docs (either Fedora or Xen wiki), but I just ended up disabling SELinux on my dom0 instead of messing around with labels.
Well libvirt is in charge of labeling devices, Admins are not supposed to care at this point. I guess the question is why is it running as xend_t rather then virt_t. What is running as xend_t?
Ok, I'm a bit confused now. I agree that libvirt should be in charge of labelling devices. But if the LV is created *outside* of libvirt, I don't see how libvirt can relabel the device since libvirt doesn't 'own' the LV. Only way that I see would be to allow libvirt to access LVs. My error (from bug 747662 which I closed as a dup of this bug) had comm="xend" scontext (source context?) = system_u:system_r:xend_t:s0 - so the xend daemon seems to be xend_t. As to why not virt_t I've got no clue.
OK lets step back, is libvirtd starting up the xen image?
In this specific case, for me, no, because I'm only trying with Xen, not virt-manager/virsh. The bug author said he tried it with both libvirtd and Xen and ran into this bug. === However, if you're asking if libvirtd is directly starting up the xen image, then I'd also say no. From what I understand, libvirtd does tasks like checking the XML-based config file, convirting it into a form Xen can interpret, then hands the VM launching off to the respective hypervisor (Xen or KVM).
Well if libvirt is not fixing the label it is up to the administrator to fix the label. # semanage fcontext -a -t xen_image_t /dev/dm-8 # restorecon -R -v /dev/dm-8
Yep, which is why I said in comment 4 that the correct labels for Xen LVs should probably just be noted somewhere rather than having this behaviour regarded as a bug. It's an annoying interaction between xend and SELinux, but it's a consequence of the fact that LVs are created outside of xend, but are still used by xend.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
The proper way here is to basically do svirt for xen. But I don't really see that happening anytime soon. Moving to the upstream tracker anyways since this is a big chunk of work. However if basic xen guest creation with virt-manager creating a file image in the default location causes selinux errors, we should fix those, it might just be a virt-manager issue.
This RFE isn't going to generate any change, so closing. Adding svirt like behavior to xen will be a big task, and no one that watches this tracker is likely to initiate it. You'd probably need to become a suse or citrix customer to get it implemented :)