Hide Forgot
Description of problem: incorrect selinux policy prevents smartd from accessing LSI Megaraid connected drives Version-Release number of selected component (if applicable): selinux-policy.noarch 3.7.19-195.el6 @anaconda-RedHatEnterpriseLinux-201301301459.x86_64/6.4 How reproducible: configure harddrives connected to a LSI/MEGARAID in /etc/smartd.conf, restart smartd and watch /var/log/messages poll error-messages Steps to Reproduce: 1. edit /etc/smartd.conf as follows --- /etc/smartd.conf.bk 2013-11-27 16:44:53.201044884 +0100 +++ /etc/smartd.conf 2013-11-27 16:01:08.477045299 +0100 @@ -20,7 +20,7 @@ # Directives listed below, which will be applied to all devices that # are found. Most users should comment out DEVICESCAN and explicitly # list the devices that they wish to monitor. -DEVICESCAN -H -m root +#DEVICESCAN -H -m root # Alternative setting to ignore temperature and power-on hours reports # in syslog. @@ -143,3 +143,10 @@ # then smartd will scan for devices /dev/hd[a-l] and /dev/sd[a-z] # DEVICESCAN may be followed by any desired Directives. +# kick in long SMART-selftests every sunday @ 0100,0200,0300,0400, +# observ SMART-health-status, error-log and selftest-log +# on all 4 mounted drives, expand if more drives are added +/dev/sg1 -d megaraid,4 -H -l error -l selftest -s L/../../7/01 +/dev/sg1 -d megaraid,5 -H -l error -l selftest -s L/../../7/02 +/dev/sg1 -d megaraid,6 -H -l error -l selftest -s L/../../7/03 +/dev/sg1 -d megaraid,7 -H -l error -l selftest -s L/../../7/04 2. restart smartd via /etc/init.d/smartd restart 3. check /var/log/messages for smartd-error-messages tail -f /var/log/messages Nov 27 16:33:41 localhost smartd[10900]: smartd 5.43 2012-06-30 r3573 [x86_64-linux-2.6.32-358.el6.x86_64] (local build) Nov 27 16:33:41 localhost smartd[10900]: Copyright (C) 2002-12 by Bruce Allen, http://smartmontools.sourceforge.net Nov 27 16:33:41 localhost smartd[10900]: Opened configuration file /etc/smartd.conf Nov 27 16:33:41 localhost smartd[10900]: Configuration file /etc/smartd.conf parsed. Nov 27 16:33:41 localhost smartd[10900]: Device: /dev/sg1 [megaraid_disk_04], open() failed: cannot open /dev/megaraid_sas_ioctl_node or /dev/megadev0 Nov 27 16:33:41 localhost smartd[10900]: Device: /dev/sg1 [megaraid_disk_05], open() failed: cannot open /dev/megaraid_sas_ioctl_node or /dev/megadev0 Nov 27 16:33:41 localhost smartd[10900]: Device: /dev/sg1 [megaraid_disk_06], open() failed: cannot open /dev/megaraid_sas_ioctl_node or /dev/megadev0 Nov 27 16:33:41 localhost smartd[10900]: Device: /dev/sg1 [megaraid_disk_07], open() failed: cannot open /dev/megaraid_sas_ioctl_node or /dev/megadev0 Nov 27 16:33:41 localhost smartd[10900]: Monitoring 0 ATA and 0 SCSI devices Nov 27 16:33:41 localhost smartd[10902]: smartd has fork()ed into background mode. New PID=10902. Actual results: harddisk could not be accessed Expected results: harddisk would be accessed Additional info: When startet via /usr/sbin smartd -q never via commandline everything works fine, harddisk could be accessed tail -f /var/log/messages Nov 27 16:09:12 localhost smartd[32640]: smartd 5.43 2012-06-30 r3573 [x86_64-linux-2.6.32-358.el6.x86_64] (local build) Nov 27 16:09:12 localhost smartd[32640]: Copyright (C) 2002-12 by Bruce Allen, http://smartmontools.sourceforge.net Nov 27 16:09:12 localhost smartd[32640]: Opened configuration file /etc/smartd.conf Nov 27 16:09:12 localhost smartd[32640]: Configuration file /etc/smartd.conf parsed. Nov 27 16:09:12 localhost smartd[32640]: Device: /dev/sg1 [megaraid_disk_04], opened Nov 27 16:09:12 localhost smartd[32640]: Device: /dev/sg1 [megaraid_disk_04], [FUJITSU MBE2147RC 5204], lu id: 0x500000e118fb5af0, 146 GB Nov 27 16:09:12 localhost smartd[32640]: Device: /dev/sg1 [megaraid_disk_04], is SMART capable. Adding to "monitor" list. Nov 27 16:09:12 localhost smartd[32640]: Device: /dev/sg1 [megaraid_disk_05], opened Nov 27 16:09:12 localhost smartd[32640]: Device: /dev/sg1 [megaraid_disk_05], [FUJITSU MBE2147RC 5204], lu id: 0x500000e118fcc370, 146 GB Nov 27 16:09:12 localhost smartd[32640]: Device: /dev/sg1 [megaraid_disk_05], is SMART capable. Adding to "monitor" list. Nov 27 16:09:12 localhost smartd[32640]: Device: /dev/sg1 [megaraid_disk_06], opened Nov 27 16:09:12 localhost smartd[32640]: Device: /dev/sg1 [megaraid_disk_06], [FUJITSU MBE2147RC 5204], lu id: 0x500000e118fcc450, 146 GB Nov 27 16:09:12 localhost smartd[32640]: Device: /dev/sg1 [megaraid_disk_06], is SMART capable. Adding to "monitor" list. Nov 27 16:09:12 localhost smartd[32640]: Device: /dev/sg1 [megaraid_disk_07], opened Nov 27 16:09:12 localhost smartd[32640]: Device: /dev/sg1 [megaraid_disk_07], [FUJITSU MBE2147RC 5204], lu id: 0x500000e118fcbd00, 146 GB Nov 27 16:09:12 localhost smartd[32640]: Device: /dev/sg1 [megaraid_disk_07], is SMART capable. Adding to "monitor" list. Nov 27 16:09:12 localhost smartd[32640]: Monitoring 0 ATA and 4 SCSI devices Nov 27 16:09:12 localhost smartd[32642]: smartd has fork()ed into background mode. New PID=32642. smartd starts without problems if selinux is set to permissive: # getenforce Enforcing # setenforce permissive # getenforce Permissive # /etc/init.d/smartd restart # tail -f /var/log/messages Nov 27 16:33:53 D0164531 smartd[10919]: smartd 5.43 2012-06-30 r3573 [x86_64-linux-2.6.32-358.el6.x86_64] (local build) Nov 27 16:33:53 D0164531 smartd[10919]: Copyright (C) 2002-12 by Bruce Allen, http://smartmontools.sourceforge.net Nov 27 16:33:53 D0164531 smartd[10919]: Opened configuration file /etc/smartd.conf Nov 27 16:33:53 D0164531 smartd[10919]: Configuration file /etc/smartd.conf parsed. Nov 27 16:33:53 D0164531 smartd[10919]: Device: /dev/sg1 [megaraid_disk_04], opened Nov 27 16:33:53 localhost smartd[10919]: Device: /dev/sg1 [megaraid_disk_04], [FUJITSU MBE2147RC 5204], lu id: 0x500000e118fb5af0, 146 GB Nov 27 16:33:53 localhost smartd[10919]: Device: /dev/sg1 [megaraid_disk_04], is SMART capable. Adding to "monitor" list. Nov 27 16:33:53 localhost smartd[10919]: Device: /dev/sg1 [megaraid_disk_05], opened Nov 27 16:33:53 localhost smartd[10919]: Device: /dev/sg1 [megaraid_disk_05], [FUJITSU MBE2147RC 5204], lu id: 0x500000e118fcc370, 146 GB Nov 27 16:33:54 localhost smartd[10919]: Device: /dev/sg1 [megaraid_disk_05], is SMART capable. Adding to "monitor" list. Nov 27 16:33:54 localhost smartd[10919]: Device: /dev/sg1 [megaraid_disk_06], opened Nov 27 16:33:54 localhost smartd[10919]: Device: /dev/sg1 [megaraid_disk_06], [FUJITSU MBE2147RC 5204], lu id: 0x500000e118fcc450, 146 GB Nov 27 16:33:54 localhost smartd[10919]: Device: /dev/sg1 [megaraid_disk_06], is SMART capable. Adding to "monitor" list. Nov 27 16:33:54 localhost smartd[10919]: Device: /dev/sg1 [megaraid_disk_07], opened Nov 27 16:33:54 localhost smartd[10919]: Device: /dev/sg1 [megaraid_disk_07], [FUJITSU MBE2147RC 5204], lu id: 0x500000e118fcbd00, 146 GB Nov 27 16:33:54 localhost smartd[10919]: Device: /dev/sg1 [megaraid_disk_07], is SMART capable. Adding to "monitor" list. Nov 27 16:33:54 localhost smartd[10919]: Monitoring 0 ATA and 4 SCSI devices Nov 27 16:33:54 localhost smartd[10921]: smartd has fork()ed into background mode. New PID=10921. btw: According to https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/6.4_Technical_Notes/selinux-policy.html that problem should be knowm via BZ#809716 which is - again - a private bug, i.e. content not visible to the average bugzilla-user, and fixed with RHBA-2013:0314, which in turn provides the package selinux-policy-3.7.19-195.el6.noarch use by me and showing the exact error. summary of BZ#809716 is or was: Due to an incorrect SELinux policy, the smartd daemon was not able to create the megaraid_sas_ioctl_node device with the correct SELinux security context. Consequently, monitoring of some disks on a MegaRAID controller using smartd was prevented. This update provides SELinux rules that allow monitoring of disks on a MegaRAID controller using smartd.
This request was not resolved in time for the current release. Red Hat invites you to ask your support representative to propose this request, if still desired, for consideration in the next release of Red Hat Enterprise Linux.
Could you attach AVC msg which you are getting?
How to obtain those, please advise... Can't see any avc-messages in /var/log/message except for those where i dis- or enabled selinux via setenforce-command.
You can check /var/log/audit/audit.log. # ausearch -m avc
Okay. I did a /etc/init.d/smartd restart which yielded following result (only last entry of ausearch posted): time->Tue Dec 10 15:48:35 2013 type=SYSCALL msg=audit(1386686915.503:16074): arch=c000003e syscall=2 success=yes exit=4 a0=7f988bebca95 a1=2 a2=7f988b06bed8 a3=16 items=0 ppid=16154 pid=16155 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=2371 comm="smartd" exe="/usr/sbin/smartd" subj=unconfined_u:system_r:fsdaemon_t:s0 key=(null) type=AVC msg=audit(1386686915.503:16074): avc: denied { open } for pid=16155 comm="smartd" name="megaraid_sas_ioctl_node" dev=devtmpfs ino=2780174 scontext=unconfined_u:system_r:fsdaemon_t:s0 tcontext=unconfined_u:object_r:device_t:s0 tclass=chr_file type=AVC msg=audit(1386686915.503:16074): avc: denied { read write } for pid=16155 comm="smartd" name="megaraid_sas_ioctl_node" dev=devtmpfs ino=2780174 scontext=unconfined_u:system_r:fsdaemon_t:s0 tcontext=unconfined_u:object_r:device_t:s0 tclass=chr_file
How is /dev/sg1 labeled now? # ls -Z /dev/sg1
# ls -Z /dev/sg1 crw-rw----. root disk system_u:object_r:scsi_generic_device_t:s0 /dev/sg1
There is a race condition. If you run /etc/init.d/smartd restart you get it again, right?
What do i get again? I you refer to the selinux-error-messages: yes, i do get them everytime i (re)start the smartd-daemon via /etc/init.d/smartd.
Does the smartd script recreated the sgi device?
The /dev/sg1-device seems to be persistent: [root@D0164531 ~]# ps -ef|grep smartd root 10194 10135 0 08:50 pts/1 00:00:00 grep smartd root 16157 1 0 2013 ? 00:00:03 /usr/sbin/smartd -q never [root@D0164531 ~]# ls -Z /dev/sg1; ls -l /dev/sg1 crw-rw----. root disk system_u:object_r:scsi_generic_device_t:s0 /dev/sg1 crw-rw----. 1 root disk 21, 1 26. Nov 15:25 /dev/sg1 [root@D0164531 ~]# /etc/init.d/smartd restart smartd beenden: [ OK ] smartd starten: [ OK ] [root@D0164531 ~]# ls -Z /dev/sg1; ls -l /dev/sg1 crw-rw----. root disk system_u:object_r:scsi_generic_device_t:s0 /dev/sg1 crw-rw----. 1 root disk 21, 1 26. Nov 15:25 /dev/sg1 [root@D0164531 ~]# /etc/init.d/smartd stop smartd beenden: [ OK ] [root@D0164531 ~]# ps -ef|grep smartd root 12556 10135 0 08:52 pts/1 00:00:00 grep smartd [root@D0164531 ~]# ls -Z /dev/sg1; ls -l /dev/sg1 crw-rw----. root disk system_u:object_r:scsi_generic_device_t:s0 /dev/sg1 crw-rw----. 1 root disk 21, 1 26. Nov 15:25 /dev/sg1 Or is there any other clue to track if the character-device is recreated? Furthermore i can't see any device-links created in /etc/init.d/smartd or via /etc/smartd.conf.
Miroslav why are we looking at sd1 rather then "megaraid_sas_ioctl_node type=AVC msg=audit(1386686915.503:16074): avc: denied { open } for pid=16155 comm="smartd" name="megaraid_sas_ioctl_node" dev=devtmpfs ino=2780174 scontext=unconfined_u:system_r:fsdaemon_t:s0 tcontext=unconfined_u:object_r:device_t:s0 tclass=chr_file The problem is this char file is mislabeled.
I am getting this problem as well on several RHEV 6 systems. # ls -lZ /dev/megaraid_sas_ioctl_node c---------. root root system_u:object_r:device_t:s0 /dev/megaraid_sas_ioctl_node # restorecon -v /dev/megaraid_sas_ioctl_node restorecon reset /dev/megaraid_sas_ioctl_node context system_u:object_r:device_t:s0->system_u:object_r:fixed_disk_device_t:s0 # ls -lZ /dev/megaraid_sas_ioctl_node c---------. root root system_u:object_r:fixed_disk_device_t:s0 /dev/megaraid_sas_ioctl_node And then restarting smartd shows no further errors. I haven't confirmed this, but anecdotally it looks like the problem may reoccur following a system reboot. Am I correct in thinking that this means the selinux-policy is already correct, since restorecon knows what type it ought to be, but whatever is (re)creating the device file (smartd? udev?) is for whatever reason creating it with the wrong type? Ie, perhaps the bug component ought to be changed?
The device is being created by something other then udev, which would label it correctly. When udev realizes their is a mislabeled file it fixes the label. We have a fix for this in RHEL7. In RHEL6 we should probably allow fsdaemon_t to manage device_t char_file. It can already manage fixed disk, so it is pretty much unconfined.
Added rule dev_rw_generic_chr_files(fsdaemon_t). Patch sent to Mirek.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2014-1568.html