Summary: SELinux is preventing /usr/bin/qemu-kvm "getattr" access on /dev/sdh1. Detailed Description: SELinux denied access requested by qemu-kvm. It is not expected that this access is required by qemu-kvm and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://docs.fedoraproject.org/selinux-faq-fc5/#id2961385) Please file a bug report. Additional Information: Source Context system_u:system_r:svirt_t:s0:c5,c126 Target Context system_u:object_r:fixed_disk_device_t:s0 Target Objects /dev/sdh1 [ blk_file ] Source qemu-kvm Source Path /usr/bin/qemu-kvm Port <Unknown> Host (removed) Source RPM Packages qemu-system-x86-0.11.0-13.fc12 Target RPM Packages Policy RPM selinux-policy-3.6.32-110.fc12 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Plugin Name catchall Host Name (removed) Platform Linux (removed) 2.6.32.11-99.fc12.x86_64 #1 SMP Mon Apr 5 19:59:38 UTC 2010 x86_64 x86_64 Alert Count 1 First Seen Sat 24 Apr 2010 08:51:30 AM EDT Last Seen Sat 24 Apr 2010 08:51:30 AM EDT Local ID 9dd8673e-b2f8-4ae9-a482-369e22c8958a Line Numbers Raw Audit Messages node=(removed) type=AVC msg=audit(1272113490.895:40896): avc: denied { getattr } for pid=3219 comm="qemu-kvm" path="/dev/sdh1" dev=devtmpfs ino=11267410 scontext=system_u:system_r:svirt_t:s0:c5,c126 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file node=(removed) type=SYSCALL msg=audit(1272113490.895:40896): arch=c000003e syscall=4 success=no exit=-13 a0=1659ea5 a1=7fff1705aed0 a2=7fff1705aed0 a3=7fff1705ac60 items=0 ppid=1 pid=3219 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="qemu-kvm" exe="/usr/bin/qemu-kvm" subj=system_u:system_r:svirt_t:s0:c5,c126 key=(null) Hash String generated from catchall,qemu-kvm,svirt_t,fixed_disk_device_t,blk_file,getattr audit2allow suggests: #============= svirt_t ============== allow svirt_t fixed_disk_device_t:blk_file getattr;
This is either libvirt failing to label, or udev stepped in an relabelled the device back to fixed_disk_device_t. Was this working for a while and then stopped? Or did it blow up right away?
This happened right away. I was using the "Add Hardware" function to try to get the USB ports on my system functioning so that I could then read a USB memory stick.
It might be the udev problem we had. But I will wait for libvirt guys to confirm.
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Hmm, is this regularly reproducible? Could be the udev issue dan mentioned. Closing for now, please reopen if anyone can still reproduce against F13 or later.