Description of problem: Smartd is unable to access drives on my 3ware 9500 raid card to monitor them. When I start smartd I get the following messages in the log: Jan 3 12:48:47 whitestar smartd[23464]: smartd version 5.38 [x86_64-redhat-linux-gnu] Copyright (C) 2002-8 Bruce Allen Jan 3 12:48:47 whitestar smartd[23464]: Home page is http://smartmontools.sourceforge.net/#012 Jan 3 12:48:47 whitestar smartd[23464]: Opened configuration file /etc/smartd.conf Jan 3 12:48:47 whitestar smartd[23464]: Drive: /dev/sda, implied '-a' Directive on line 57 of file /etc/smartd.conf Jan 3 12:48:47 whitestar smartd[23464]: Drive: /dev/sdb, implied '-a' Directive on line 58 of file /etc/smartd.conf Jan 3 12:48:47 whitestar smartd[23464]: Configuration file /etc/smartd.conf parsed. Jan 3 12:48:47 whitestar smartd[23464]: Device: /dev/sda, opened Jan 3 12:48:47 whitestar smartd[23464]: Device: /dev/sda, not found in smartd database. Jan 3 12:48:47 whitestar smartd[23464]: Device: /dev/sda, is SMART capable. Adding to "monitor" list. Jan 3 12:48:47 whitestar smartd[23464]: Device: /dev/sdb, opened Jan 3 12:48:47 whitestar smartd[23464]: Device: /dev/sdb, not found in smartd database. Jan 3 12:48:48 whitestar smartd[23464]: Device: /dev/sdb, is SMART capable. Adding to "monitor" list. Jan 3 12:48:48 whitestar smartd[23464]: Device: /dev/twa0 [3ware_disk_00], File exists, open() failed Jan 3 12:48:48 whitestar smartd[23464]: Unable to register ATA device /dev/twa0 [3ware_disk_00] at line 89 of file /etc/smartd.conf Jan 3 12:48:48 whitestar smartd[23464]: Device /dev/twa0 [3ware_disk_00] not available Jan 3 12:48:48 whitestar smartd[23464]: Device: /dev/twa0 [3ware_disk_01], File exists, open() failed Jan 3 12:48:48 whitestar smartd[23464]: Unable to register ATA device /dev/twa0 [3ware_disk_01] at line 90 of file /etc/smartd.conf Jan 3 12:48:48 whitestar smartd[23464]: Device /dev/twa0 [3ware_disk_01] not available Jan 3 12:48:48 whitestar smartd[23464]: Monitoring 2 ATA and 0 SCSI devices Jan 3 12:48:48 whitestar smartd[23482]: smartd has fork()ed into background mode. New PID=23482. Jan 3 12:48:50 whitestar setroubleshoot: SELinux is preventing /usr/sbin/smartd "getattr" access to device /dev/twa0. For complete SELinux messages. run sealert -l 78229cca-443e-497a-885b-46d2a1c2597f Jan 3 12:48:50 whitestar setroubleshoot: SELinux is preventing /usr/sbin/smartd "getattr" access to device /dev/twa0. For complete SELinux messages. run sealert -l 78229cca-443e-497a-885b-46d2a1c2597f Version-Release number of selected component (if applicable): How reproducible: Every time. Steps to Reproduce: 1. Start smartd. 2. 3. Actual results: Able to monitor all drives. Expected results: Only able to monitor directly connected SATA drives. Unable to monitor drives connected to the 3ware card. Additional info: The /dev/tw* nodes have the selinux type 'device_t' which is a bug according to the sealert message. This problem can be solved by changing the selinux type on the 3ware device node to fixed_disk_device_t with the command 'chcon -t fixed_disk_device_t /dev/tw*'.
The problem is who created these fixed disks with the wrong label. First make sure you have the latest policy installed. yum update selinux-policy-targeted --enablerepo=updates-testing selinux-policy-3.6.32-63.fc12.noarch has a line that says if smartmon creates a device it will label it fixed_disk_device_t. Udev should also create it with the right label. If some other process is creating the device, we need to fix this.
I currently have selinux-policy-3.6.32-59.fc12.noarch installed. I tried the command 'restorecon /dev/tw*' with this version of selinux and it correctly sets the type to fixed_disk_device_t. I did notice that creating the node by hand with the mknod program leaves the device with type device_t (but a subsequent restorecon resets the type correctly). I don't know when or what program created these device nodes. I've had the 3ware raid card in this system since 2004 when the system was running FC1. Is there some test I can run for you to determine which program is/should creating the nodes? I do have my root filesystem on the discs hanging off this 3ware card so I would have to be careful in what commands I tried.
What happens on reboot, are these devices labeled fixed_disk or device_t?
device_t.
ps -eZ | grep smartd Is there an init script that is doing a mknod?
Not that I see... [root@whitestar /]# cd /etc/rc.d [root@whitestar init.d]# grep mknod * */* [root@whitestar init.d]# ps -eZ | grep smartd system_u:system_r:fsdaemon_t:s0 2430 ? 00:00:00 smartd [root@whitestar init.d]# The string 'twa0' is mentioned in a couple of files: [root@whitestar /]# grep -R twa0 /bin /etc /sbin /usr |& grep -v directory /etc/smartd.conf:/dev/twa0 -d 3ware,0 -a -s L/../../2/02 /etc/smartd.conf:/dev/twa0 -d 3ware,1 -a -s L/../../3/02 /etc/smartd.conf:/dev/twa0 -d 3ware,2 -a -s L/../../4/02 /etc/smartd.conf:/dev/twa0 -d 3ware,3 -a -s L/../../5/02 /etc/smartd.conf:/dev/twa0 -d 3ware,4 -a -s L/../../6/02 /usr/share/doc/smartmontools-5.38/smartd.conf:#/dev/twa0 -d 3ware,0 -a -s L/../../2/01 /usr/share/doc/smartmontools-5.38/smartd.conf:#/dev/twa0 -d 3ware,1 -a -s L/../../2/03 Binary file /usr/sbin/smartd matches Binary file /usr/sbin/smartctl matches [root@whitestar /]# Grepping for /dev/twa gives the exact same results. Grepping for 'twa' gives far too many files as it matches words like 'software', 'netwatch', etc. Grepping for 'twa%d' yields no results.
I managed to track it down. Its the '3ware Disk Manager 2' program that's creating the device nodes with the wrong type. If I change the startup order so that smartd runs immediately before this daemon then the device types are created correctly. I'm currently running version 2.04.00.035 of 3dm2 from atrpms.net. The original executable is from 3ware.com. === [root@whitestar projects]# rpm -q 3dm2 3dm2-2.04.00.035-8.at.x86_64 [root@whitestar projects]# rpm -qi 3dm2 Name : 3dm2 Relocations: (not relocatable) Version : 2.04.00.035 Vendor: ATrpms.net Release : 8.at Build Date: Fri 02 Feb 2007 03:46:41 PM EST Install Date: Thu 19 Feb 2009 11:44:20 AM EST Build Host: octopus.physik.fu-berlin.de Group : System Environment/Base Source RPM: 3dm2-2.04.00.035-8.at.src.rpm Size : 8587526 License: 3ware Signature : DSA/SHA1, Fri 02 Feb 2007 03:46:43 PM EST, Key ID 508ce5e666534c2b Packager : ATrpms <http://ATrpms.net/> URL : http://www.3ware.com/ Summary : 3ware® Disk Manager Description : 3ware Disk Manager 2 (3DM 2) allows you to manage and view the status of 3ware RAID controllers and associated drives. 3DM runs as a service under Microsoft Windows, and as a daemon under Linux. When it is running, you can use your browser to view status and perform administrative tasks locally or remotely. 3DM can display information about 3ware RAID 7000-, 8000- and 9000-series RAID controllers. However, some version 2 features are only available for 9000-series controllers. Two levels of access are provided: user and administrator. Users have view-only access, and can check the status of drives and units. Administrators can view and make changes, using 3DM to configure RAID units and designate hot spares, and to perform maintenance tasks on RAID units. === I haven't tried downloading and installing the latest version (2.09.01.004) of the '3dm2' application from 3ware.com to see if it makes any difference. Have you worked with 3ware to make this application selinux aware?
Should not have to, What is the path to the executable? If you chcon -t fsdaemon_exec_t PATHTO/3dm2 Does everything work properly? Another label that might work would be lvm_exec_t
If I change the executable type via chcon -t fsdaemon_exec_t /usr/sbin/3dm2 and then start it with run_init /etc/init.d/3dm2 start My system log starts to fill up with the message: Jan 5 09:19:55 whitestar audispd: queue is full - dropping event Three or four times a second the log file contains the message: Jan 5 09:20:05 whitestar setroubleshoot: SELinux is preventing /usr/sbin/3dm2 "execmem" access. For complete SELinux messages. run sealert -l 91476057-fd36-4e7c-9512-254d3fd8a680 I also see: Jan 5 09:20:02 whitestar setroubleshoot: SELinux is preventing /usr/sbin/3dm2 "create" access to device twa0. For complete SELinux messages. run sealert -l 8dc23810-4fc5-4c9b-b350-33ca396c3767 Jan 5 09:20:03 whitestar setroubleshoot: SELinux is preventing /usr/sbin/3dm2 "write" access on /etc/3dm2/3dm2.conf. For complete SELinux messages. run sealert -l 380dee92-f0d3-4cb8-b96c-31b9c7a10221 The twa* device files are not present after running this command. === If I change the executable type via chcon -t lvm_exec_t /usr/sbin/3dm2 and then start it with run_init /etc/init.d/3dm2 start I get no messages in the log. The twa* devices are all created with type device_t, and then the program is killed with no message. === I'm not sure that either of these executable types will work. The 3dm2 program also wants to open a tcp socket (default port 888) and listen for incoming ssl connections from a web browser. It then presents the current hard drive state back to the client as a series of web pages.
Created attachment 381781 [details] Full info on the selinux create denial
Created attachment 381782 [details] Full info on the selinux write denial
Ok so I guess leaving it as bin_t is a better idea. Are you saying you just need to start the smartd init script before the 3dm2 script and everything works?
Yes. If I change the smartd links in /etc/rc?.d to start at priority 39 (3dm2 defaults to 40) then everything works correctly. I'm not averse to trying to write a policy for this daemon, I just haven't written any policies in four years.
Go for it. Use sepolgen to get started.
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping