Description of problem: SELinux denies smartd access to /dev/sg* Version-Release number of selected component (if applicable): smartmontools-5.38-2.el5 selinux-policy-2.4.6-255.el5_4.1 How reproducible: The disks of my system are exposed as /dev/sg[123] by the Adaptec RAID Controller (aacraid). Steps to Reproduce: 1. Find a system using an Adaptec aacraid Controller 2. Add a line such as this in "/etc/smartd.conf": /dev/sg1 -H -o on -S on -s (S/../.././12|L/../../5/08) -l error -l selftest -f -p -u -W 5,40,50 -m root 3. "service smartd start" Actual results: [root@saur ~]# sealert -l 2b2200cb-5933-4587-904f-66a5d2d43cdd Summary: SELinux is preventing smartd (fsdaemon_t) "read write" to sg1 (scsi_generic_device_t). Detailed Description: [SELinux is in permissive mode, the operation would have been denied but was permitted due to permissive mode.] SELinux denied access requested by smartd. It is not expected that this access is required by smartd 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: Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for sg1, restorecon -v 'sg1' If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Context system_u:system_r:fsdaemon_t Target Context system_u:object_r:scsi_generic_device_t Target Objects sg1 [ chr_file ] Source smartd Source Path /usr/sbin/smartd Port <Unknown> Host saur.wien-ticket.at Source RPM Packages smartmontools-5.38-2.el5 Target RPM Packages Policy RPM selinux-policy-2.4.6-255.el5_4.1 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Permissive Plugin Name catchall_file Host Name saur.wien-ticket.at Platform Linux saur.wien-ticket.at 2.6.18-164.6.1.el5xen #1 SMP Tue Oct 27 11:45:55 EDT 2009 x86_64 x86_64 Alert Count 58 First Seen Sun Dec 6 18:42:20 2009 Last Seen Mon Dec 14 15:44:15 2009 Local ID 2b2200cb-5933-4587-904f-66a5d2d43cdd Line Numbers Raw Audit Messages host=saur.wien-ticket.at type=AVC msg=audit(1260801855.468:22586): avc: denied { read write } for pid=3735 comm="smartd" name="sg1" dev=tmpfs ino=7406 scontext=system_u:system_r:fsdaemon_t:s0 tcontext=system_u:object_r:scsi_generic_device_t:s0 tclass=chr_file host=saur.wien-ticket.at type=SYSCALL msg=audit(1260801855.468:22586): arch=c000003e syscall=2 success=yes exit=3 a0=2b1c801b8810 a1=802 a2=0 a3=8 items=0 ppid=1 pid=3735 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="smartd" exe="/usr/sbin/smartd" subj=system_u:system_r:fsdaemon_t:s0 key=(null) Expected results: No such error message Additional info:
this seems like job for selinux, re-assigning
Miroslav add storage_read_scsi_generic(fsdaemon_t) storage_write_scsi_generic(fsdaemon_t)
Fixed in selinux-policy-2.4.6-267.el5.noarch
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2010-0182.html