DescriptionRichard W.M. Jones
2014-02-12 13:50:54 UTC
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
Comment 1Richard W.M. Jones
2014-02-12 14:22:31 UTC
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.
Comment 3Richard W.M. Jones
2014-02-14 17:45:29 UTC
.. 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.
Comment 4M. Edward (Ed) Borasky
2014-07-13 06:55:51 UTC
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?
Comment 7Richard W.M. Jones
2015-04-26 08:14:05 UTC
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