Description of problem: SELinux is preventing /usr/sbin/skdump from 'read' accesses on the blk_file sda. ***** Plugin catchall (100. confidence) suggests *************************** If you believe that skdump should be allowed read access on the sda blk_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 skdump /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:abrt_t:s0-s0:c0.c1023 Target Context system_u:object_r:fixed_disk_device_t:s0 Target Objects sda [ blk_file ] Source skdump Source Path /usr/sbin/skdump Port <Unknown> Host (removed) Source RPM Packages libatasmart-0.19-4.fc19.i686 Target RPM Packages Policy RPM selinux-policy-3.12.1-54.fc19.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 3.9.6-301.fc19.i686 #1 SMP Mon Jun 17 14:47:53 UTC 2013 i686 i686 Alert Count 1 First Seen 2013-06-23 23:18:35 IST Last Seen 2013-06-23 23:18:35 IST Local ID 33a1fb9b-0552-412a-821b-a26a9716454a Raw Audit Messages type=AVC msg=audit(1372009715.406:403): avc: denied { read } for pid=3907 comm="skdump" name="sda" dev="devtmpfs" ino=1170 scontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file type=SYSCALL msg=audit(1372009715.406:403): arch=i386 syscall=open success=no exit=EACCES a0=99756a0 a1=88900 a2=0 a3=8 items=0 ppid=3905 pid=3907 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm=skdump exe=/usr/sbin/skdump subj=system_u:system_r:abrt_t:s0-s0:c0.c1023 key=(null) Hash: skdump,abrt_t,fixed_disk_device_t,blk_file,read Additional info: reporter: libreport-2.1.5 hashmarkername: setroubleshoot kernel: 3.9.6-301.fc19.i686 type: libreport Potential duplicate: bug 799713
I thought it had been changed. https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=800574
No, it wasn't.
Lets don't audit it, until it is fixed.
*** This bug has been marked as a duplicate of bug 800574 ***