Description of problem: Just following the instructions in the alert box [root@hoho2 sql-ledger-progs]# /sbin/restorecon -v /dev/sda [root@hoho2 sql-ledger-progs]# ls -lZ /dev/sda brw-r----- root disk system_u:object_r:fixed_disk_device_t /dev/sda [root@hoho2 sql-ledger-progs]# Didn't seem to change status, so filed this bug report Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. Noticed yellow star on menu bar 3. click on yellow star - read alerts Actual results: No alerts (Would also like to turn on strict selinux as well - one of these days. Expected results: Additional info: Summary SELinux is preventing /usr/sbin/smartd (fsdaemon_t) "read write" access to device sda. Detailed Description SELinux has denied the /usr/sbin/smartd (fsdaemon_t) "read write" access to device sda. sda 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 sda. If this device remains labeled device_t, then this is a bug in SELinux policy. Please file a http://bugzilla.redhat.com/bugzilla/enter_bug.cgi 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 sda, you can use chcon -t SIMILAR_TYPE sda, If this fixes the problem, you can make this permanent by executing semanage fcontext -a -t SIMILAR_TYPE sda 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 http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against this application. Allowing Access Attempt restorecon -v sda or chcon -t SIMILAR_TYPE sda Additional Information Source Context system_u:system_r:fsdaemon_t Target Context system_u:object_r:device_t Target Objects sda [ blk_file ] Affected RPM Packages smartmontools-5.36-3.2.fc6 [application] Policy RPM selinux-policy-2.4.6-17.fc6 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Permissive Plugin Name plugins.device Host Name hoho2.chidig.com Platform Linux hoho2.chidig.com 2.6.18-1.2869.fc6 #1 SMP Wed Dec 20 14:51:46 EST 2006 i686 i686 Alert Count 21 First Seen Fri 12 Jan 2007 07:58:40 PM CST Last Seen Tue 16 Jan 2007 02:28:40 PM CST Local ID 48b377dc-48b4-4fea-9433-dc4d27d5dcf5 Line Numbers Raw Audit Messages avc: denied { read, write } for comm="smartd" dev=tmpfs egid=0 euid=0 exe="/usr/sbin/smartd" exit=3 fsgid=0 fsuid=0 gid=0 items=0 name="sda" pid=2523 scontext=system_u:system_r:fsdaemon_t:s0 sgid=0 subj=system_u:system_r:fsdaemon_t:s0 suid=0 tclass=blk_file tcontext=system_u:object_r:device_t:s0 tty=(none) uid=0 Not so easy to find version... [root@hoho2 sql-ledger-progs]# /sbin/restorecon --version /sbin/restorecon: invalid option -- - usage: /sbin/restorecon [-iFnrRv] [-e excludedir ] [-o filename ] [-f filename | pathname... ] [root@hoho2 sql-ledger-progs]# /sbin/restorecon -V /sbin/restorecon: invalid option -- V usage: /sbin/restorecon [-iFnrRv] [-e excludedir ] [-o filename ] [-f filename | pathname... ] [root@hoho2 sql-ledger-progs]# /sbin/restorecon --help /sbin/restorecon: invalid option -- - usage: /sbin/restorecon [-iFnrRv] [-e excludedir ] [-o filename ] [-f filename | pathname... ] [root@hoho2 sql-ledger-progs]#
You reported this as an 5c7 bug but put in a fc6 bug report? The cause of this problem is a mislabeled /dev/sda device. For some reason this device was not created with the correct context. If it was not created via udev, then what ever is creating it did not set it correctly. If it is created in an init script you need to add a line restorecon /dev/sda right after the mknod.
I am running an uptodate F7 system. I copied the info from the setroubleshooter window. If it is wrong, then something in the se initialization gets it wrong. My system (where I wrote the bug) is: [root@hoho2 ThyraAccounts]# cat /proc/version Linux version 2.6.21-1.3228.fc7 (kojibuilder.redhat.com) (gcc version 4.1.2 20070502 (Red Hat 4.1.2-12)) #1 SMP Tue Jun 12 15:37:31 EDT 2007 [root@hoho2 ThyraAccounts]# ---------------------------------- The sda,b devices are scsi which are hooked up as RAID 1. The installation process (anaconda) for F7 is very unfriendly to RAID/LVM (see bug 242043 bug 241949 bug 237415 ). Since I am using the RAID 1 implemented in FC6, maybe that is where the fc6 comes from. An open question. All of my fixed disks have the same ls -lZ response: brw-r----- root disk system_u:object_r:fixed_disk_device_t sda brw-r----- root disk system_u:object_r:fixed_disk_device_t sda1 brw-r----- root disk system_u:object_r:fixed_disk_device_t sda2 brw-r----- root disk system_u:object_r:fixed_disk_device_t sda3 brw-r----- root disk system_u:object_r:fixed_disk_device_t sdb brw-r----- root disk system_u:object_r:fixed_disk_device_t sdb1 brw-r----- root disk system_u:object_r:fixed_disk_device_t sdb2 brw-r----- root disk system_u:object_r:fixed_disk_device_t sdb3 I have a hazy idea of what selinux is trying to do, but restorecon does not seem to have much effect on any of these disks. The partitions 1,2,3 are /boot /swap /root (LVM). The smartd application goes out to the disk hardware itself and queries various registers to determine how hot it is and how many errors the disk has accumulated since the last time it was queried. It mostly reads, but may write to reset registers in the disk - don't know for sure. smartd is quite helpful to me on a long term basis. I saw high temperatures and I was able to get an extra fan and vacuum out the fuzz balls early enough to prevent trouble...
Ok, could you update to the latest selinux-policy for fc7. Then see if these messages are still happening. What is being reported was a device was created in /dev/ named sda, this had the directory label device_t on it rather then the fixed_disk_device_t label that udev should have put on it at the time smart tried to use it, and was denied by SELinux. The question was this only a problem during the upgrade or are you continuing to see it?
Yeah, I think it is OK. The Jan 12 date of the bug was my 'pilot error'. I looked in the setroubleshoot browser and saw Jun 12... Not a new problem.