Description of problem: It's unclear what exactly went wrong here. I was running the libguestfs test suite, when this error was printed: ----------- 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: internal error: process exited while connecting to monitor: qemu: could not load kernel '/home/rjones/d/libguestfs-1.24/tmp/.guestfs-1000/kernel.18148': Permission denied [code=1 domain=10] 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: internal error: early end of file from monitor: possible problem: qemu: could not load kernel '/home/rjones/d/libguestfs-1.24/tmp/.guestfs-1000/kernel.18148': Permission denied [code=1 domain=10] ----------- It is possible this is some kind of race between threads in libvirt (or libguestfs). SELinux is preventing /usr/bin/qemu-system-x86_64 from 'read' accesses on the file kernel.18148. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that qemu-system-x86_64 should be allowed read access on the kernel.18148 file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep qemu-system-x86 /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context unconfined_u:system_r:svirt_t:s0:c214,c981 Target Context unconfined_u:object_r:user_home_t:s0 Target Objects kernel.18148 [ file ] Source qemu-system-x86 Source Path /usr/bin/qemu-system-x86_64 Port <Unknown> Host (removed) Source RPM Packages qemu-system-x86-1.6.1-3.fc20.x86_64 Target RPM Packages Policy RPM selinux-policy-3.12.1-106.fc20.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 3.12.5-302.fc20.x86_64 #1 SMP Tue Dec 17 20:42:32 UTC 2013 x86_64 x86_64 Alert Count 1 First Seen 2014-02-12 13:47:15 GMT Last Seen 2014-02-12 13:47:15 GMT Local ID 28adbb9f-f1d1-403e-a94d-c87d3f8cfc9a Raw Audit Messages type=AVC msg=audit(1392212835.683:3028): avc: denied { read } for pid=18474 comm="qemu-system-x86" name="kernel.18148" dev="sdb1" ino=799903 scontext=unconfined_u:system_r:svirt_t:s0:c214,c981 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file type=SYSCALL msg=audit(1392212835.683:3028): arch=x86_64 syscall=open success=no exit=EACCES a0=7f6ad9f5d8d0 a1=0 a2=1b6 a3=1 items=0 ppid=1 pid=18474 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 ses=1 tty=(none) comm=qemu-system-x86 exe=/usr/bin/qemu-system-x86_64 subj=unconfined_u:system_r:svirt_t:s0:c214,c981 key=(null) Hash: qemu-system-x86,svirt_t,user_home_t,file,read Additional info: reporter: libreport-2.1.10 hashmarkername: setroubleshoot kernel: 3.12.5-302.fc20.x86_64 type: libreport Potential duplicate: bug 988996
Another thought about this bug: I was running two separate sets of libguestfs tests. These use different directories, and therefore different appliances, kernels etc. However because of the design of libvirt, they will share a single libvirtd process.
It looks like the kernel.18148 was not relabeled.
.. which would be a libvirt bug, since it's supposed to be doing the labelling. There is at least one known race in libvirt labelling (bug 871196). However I'm fairly sure this can't be the same thing.
Description of problem: Starting up VirtManager Additional info: reporter: libreport-2.2.2 hashmarkername: setroubleshoot kernel: 3.15.3-200.fc20.x86_64 type: libreport
Description of problem: 1. Compile gnome-boxes from git on fedora 20 2. Create a VM in Boxes 3. Click on the VM to start it Additional info: reporter: libreport-2.2.3 hashmarkername: setroubleshoot kernel: 3.11.10-301.fc20.x86_64 type: libreport
Unfortunately a couple other hits have latched onto this bug, but I'm guessing the symptom is not the same as Rich's original report. Rich, do you still these AVCs with the libguestfs test suite and newer libvirt?
No.