Bug 254011 - SELinux is preventing /usr/sbin/smartd (fsdaemon_t) "getattr" access to device /dev/twe2.
SELinux is preventing /usr/sbin/smartd (fsdaemon_t) "getattr" access to devic...
Product: Fedora
Classification: Fedora
Component: smartmontools (Show other bugs)
x86_64 Linux
low Severity low
: ---
: ---
Assigned To: Tomas Smetana
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2007-08-23 12:46 EDT by Mark Harig
Modified: 2007-12-11 13:41 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-12-11 06:55:38 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Mark Harig 2007-08-23 12:46:36 EDT
Description of problem:

From setroubleshoot browser:

SELinux has denied the /usr/sbin/smartd (fsdaemon_t) "getattr" access to device
/dev/twe2. /dev/twe2 is mislabeled, this device has the default label of the
/dev directory, which should not happen. All Character and/or Block Devices
should have a label. You can attempt to change the label of the file using
restorecon -v /dev/twe2. If this device remains labeled device_t, then this is a
bug in SELinux policy. Please file a bug report against the selinux-policy
package. If you look at the other similar devices labels, ls -lZ /dev/SIMILAR,
and find a type that would work for /dev/twe2, you can use chcon -t SIMILAR_TYPE
/dev/twe2, If this fixes the problem, you can make this permanent by executing
semanage fcontext -a -t SIMILAR_TYPE /dev/twe2 If the restorecon changes the
context, this indicates that the application that created the device, created it
without using SELinux APIs. If you can figure out which application created the
device, please file a bug report against this application.

Version-Release number of selected component (if applicable):
# rpm -q smartmontools selinux-policy-targeted

How reproducible:

Every time I restart the 'smartd' service.

Steps to Reproduce:
1. Log on as 'root', or prefix the following command with 'su -c '
2. Enter the following at the shell prompt: /sbin/service smartd restart

Actual results:
The setroubleshoot browser alert is triggered and email is sent to my alert
email address.  The setroubleshoot browser displays the message that I have
included in this report, including the Summary line, Description, and Additional

Expected results:
The smartd service should start with no SELinux alerts.

Additional info:

Here are the instances of the string 'twe' in /etc/smartd.conf
   # grep -i twe /etc/smartd.conf
   /dev/twe0 -d 3ware,0 -H
   /dev/twe0 -d 3ware,1 -H

The setroubleshoot browser makes the following recommendation:

    Attempt restorecon -v /dev/twe2 or chcon -t SIMILAR_TYPE /dev/twe2

I have not done this for /dev/twe2 because there is only one (hardware) RAID
card on the computer (3ware Inc 7xxx/8xxx-series PATA/SATA-RAID), so only
/dev/twe0 corresponds to an actual, physical device.  Before this error, above,
was reported by SELinux for /dev/twe2, it was reporting the same error for
/dev/twe1, which also does not exist.  In that case, I ran the recommended
command for /dev/twe1 (i.e., 'restorecon -v /dev/twe1'), and then restarted the
smartd service (i.e., '/sbin/service smartd restart).

This appears to me to be a problem with smartmontools.  It appears to be
attempting to retrieve information about devices that do not exist (/dev/twe1,
/dev/twe2, etc.), and which are not configured in the configuration file

Additional Information from setroubleshoot:

Target Context:  user_u:object_r:device_t
Target Objects:  /dev/twe2 [ chr_file ]
Affected RPM Packages:  smartmontools-5.37-3.1.fc7[application]
Policy RPM:  selinux-policy-2.6.4-33.fc7
Selinux Enabled:  True
Policy Type:  targeted
MLS Enabled:  True
Enforcing Mode:  Enforcing
Plugin Name:  plugins.device
Host Name:  localhost
Platform:  Linux localhost #1 SMP Fri Jul 27 18:21:43 EDT 2007
x86_64 x86_64
Alert Count:  1
First Seen:  Thu 23 Aug 2007 11:49:42 AM EDT
Last Seen:  Thu 23 Aug 2007 11:49:42 AM EDT
Local ID:  85e7b884-b33f-4859-90f0-6b6c9c13489e
Line Numbers:  

Raw Audit Messages :

avc: denied { getattr } for comm="smartd" dev=tmpfs egid=0 euid=0
exe="/usr/sbin/smartd" exit=-13 fsgid=0 fsuid=0 gid=0 items=0 name="twe2"
path="/dev/twe2" pid=6969 scontext=user_u:system_r:fsdaemon_t:s0 sgid=0
subj=user_u:system_r:fsdaemon_t:s0 suid=0 tclass=chr_file
tcontext=user_u:object_r:device_t:s0 tty=(none) uid=0
Comment 1 Tomas Smetana 2007-08-28 06:36:37 EDT
There seems to be a code that really stats all the possible 3ware nodes and even
creates them if not found.  But I really don't know if I should touch this code
-- I have no 3ware card around to test the possible code changes.
Comment 2 Tomas Smetana 2007-12-11 06:55:38 EST
Sorry.  I simply can't fix this one (or do much about it) -- I have nowhere to
reproduce/test it.
Comment 3 Mark Harig 2007-12-11 13:41:32 EST
OK.  If I am able to produce more detailed information, I will report it here.

Note You need to log in before you can comment on or make changes to this bug.