Description of problem: SELinux denied access requested by /usr/sbin/smartd. It is not expected that this access is required by /usr/sbin/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. Version-Release number of selected component (if applicable): How reproducible: Every time I restart the 'smartd' service Each time I issue the command (as 'root'): # /sbin/service smartd restart Steps to Reproduce: 1. Log on as 'root'. 2. Start a terminal window. 3. Issue the following command at the shell prompt: /sbin/service smartd restart Actual results: The setroubleshoot browser displays an alert. When I start that browser, it displays the summary and description that I have included above. Expected results: The smartd service should restart without causing the setroubleshoot browser to issue an alert. Additional info: Source Context: system_u:system_r:fsdaemon_t Target Context: system_u:object_r:device_t Target Objects: / [ dir ] Affected RPM: smartmontools-5.37-3.fc7[application]filesystem-2.4.6-1.fc7 Packages: [target] Policy RPM: selinux-policy-2.6.4-33.fc7 Selinux Enabled: True Policy Type: targeted MLS Enabled: True Enforcing Mode: Enforcing Plugin Name: plugins.catchall_file Host Name: localhost Platform: Linux localhost 2.6.22.1-41.fc7 #1 SMP Fri Jul 27 18:21:43 EDT 2007 x86_64 x86_64 Alert Count: 12 First Seen: Wed 15 Aug 2007 05:51:24 PM EDT Last Seen: Sun 19 Aug 2007 08:13:18 PM EDT Local ID: e4bded9f-0bca-4770-9655-1e731bafce25 Line Numbers: Raw Audit Messages : avc: denied { write } for comm="smartd" dev=tmpfs egid=0 euid=0 exe="/usr/sbin/smartd" exit=-13 fsgid=0 fsuid=0 gid=0 items=0 name="/" pid=2726 scontext=system_u:system_r:fsdaemon_t:s0 sgid=0 subj=system_u:system_r:fsdaemon_t:s0 suid=0 tclass=dir tcontext=system_u:object_r:device_t:s0 tty=(none) uid=0
Nothing like this happened on FC-6... Maybe this has to do something with selinux-policy.
The summary line provided by SELinux says that smartd attempted to write to '/' (the root directory). Is this expected and required behavior by smartd? Or should smartd only be writing to log files? Or is SELinux mistaken in reporting that smartd is attempting write to '/'? (Running 'strace' on 'smartd' on a system without SELinux should help to answer the last question.)
On further investigation, I would like for this report to be set to closed. I was reporting a problem that is no longer being reported by SELinux. The problem had be reported up until 19 Aug. It was a problem with the configuration of smartd. I will be replacing this Bugzilla report with a different one that is related to the interaction between SELinux and smartmontools.