Description of problem:SELinux is preventing hal-storage-mou (hald_t) "write" to / (fusefs_t). Version-Release number of selected component (if applicable): How reproducible:Simply add a usb flash drive in case #1. The same situation occurs with an internally attached ide ntfs formated drive as well Steps to Reproduce: 1.As stated above add a USB Flash drive 2.or add a NTFS formatted IDE drive to system 3. Actual results:SELinux is preventing hal-storage-mou (hald_t) "write" to / (fusefs_t). preventing the system from adding drive Expected results:This policy differs from previous kernal version in which the USB or the IDE device is registered in the system and displayed on the desktop. Current kernal is 2.6.27.21-170.2.56.fc10.i686 Additional info:SELinux denied access requested by hal-storage-mou. / may be a mislabeled. / default SELinux type is root_t, but its current type is fusefs_t. Changing this file back to the default type, may fix your problem. File contexts can be assigned to a file in the following ways. Files created in a directory receive the file context of the parent directory by default. The SELinux policy might override the default label inherited from the parent directory by specifying a process running in context A which creates a file in a directory labeled B will instead create the file with label C. An example of this would be the dhcp client running with the dhclient_t type and creates a file in the directory /etc. This file would normally receive the etc_t type due to parental inheritance but instead the file is labeled with the net_conf_t type because the SELinux policy specifies this. Users can change the file context on a file using tools such as chcon, or restorecon. This file could have been mislabeled either by user error, or if an normally confined application was run under the wrong domain. However, this might also indicate a bug in SELinux because the file should not have been labeled with this type. Additional Information: Source Context: system_u:system_r:hald_t:s0Target Context: system_u:object_r:fusefs_t:s0Target Objects: / [ dir ]Source: hal-storage-mouSource Path: /usr/libexec/hal-storage-mountPort: <Unknown>Host: localhost.localdomainSource RPM Packages: hal-0.5.12-14.20081027git.fc10Target RPM Packages: filesystem-2.4.19-1.fc10Policy RPM: selinux-policy-3.5.13-59.fc10Selinux Enabled: TruePolicy Type: targetedMLS Enabled: TrueEnforcing Mode: EnforcingPlugin Name: restoreconHost Name: localhost.localdomainPlatform: Linux localhost.localdomain 2.6.27.21-170.2.56.fc10.i686 #1 SMP Mon Mar 23 23:37:54 EDT 2009 i686 athlonAlert Count: 14First Seen: Sun 24 May 2009 03:48:22 PM EDTLast Seen: Mon 25 May 2009 06:47:51 AM EDTLocal ID: 05ed65a4-0436-4a1a-aeb9-87e4af148c78Line Numbers: Raw Audit Messages :node=localhost.localdomain type=AVC msg=audit(1243248471.768:22): avc: denied { write } for pid=3659 comm="hal-storage-mou" name="/" dev=sdb1 ino=1 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:fusefs_t:s0 tclass=dir node=localhost.localdomain type=SYSCALL msg=audit(1243248471.768:22): arch=40000003 syscall=5 success=no exit=-13 a0=804da30 a1=8042 a2=180 a3=8042 items=0 ppid=2250 pid=3659 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="hal-storage-mou" exe="/usr/libexec/hal-storage-mount" subj=system_u:system_r:hald_t:s0 key=(null) aAddition
Do you know which directory hal is trying to write into? This seems strange since we have not heard of this before, it could be a labeling problem, if some directory is labeled fusefs_t. Unless hal is writing stuff into ~/.gfs directory? Does the following command show any directories labeled fusefs_t? # find / -printf "%p %Z\n" 2> /dev/null | grep fusefs_t
To Daniel Walsh from William Henry As mysteriously as this problem began it has now disappeared. After running the command above, there was no output. I was returned to the command prompt. [quasar@localhost ~]$ # find / -printf "%p %Z\n" 2> /dev/null | grep fusefs_t [quasar@localhost ~]$ I did alter the fstab file with the following line /dev/sdb1 /media auto rw,user,defaults 0 0 In my case sdb1 is a second ntfs Win2k hard drive. after doing this all drives regained their normal behaviour. All of my external or USB mount drives beagn to register on the system even though I deleted the line in the fstab file later on. I can no longer duplicate the problem?
To Daniel Walsh from William Henry Shortly after my reply in comment #2, I received a kernel update: 2.6.27.24-170.2.68.fc10.i686. The problem has reappeared. I ran the command that you suggested and the output is appended here: [quasar@localhost ~]$ find / -printf "%p %Z\n" 2> /dev/null | grep fusefs_t /home/quasar/.gvfs system_u:object_r:fusefs_t:s0
Miroslav add fs_manage_fusefs_dirs(hald_t)
Tried the fix you suggested. Unfortunately, it doesn't appear to rectify the problem. Perhaps I applied the fix incorrectly. Attached is my etc file: # # /etc/fstab # Created by anaconda on Wed Dec 24 22:02:33 2008 # # Accessible filesystems, by reference, are maintained under '/dev/disk' # See man pages fstab(5), findfs(8), mount(8) and/or vol_id(8) for more info # /dev/VolGroup00/LogVol00 / ext3 defaults 1 1 UUID=830c55ee-edd7-48e1-9118-5cf939ca67c8 /boot ext3 defaults 1 2 tmpfs /dev/shm tmpfs defaults 0 0 devpts /dev/pts devpts gid=5,mode=620 0 0 sysfs /sys sysfs defaults 0 0 proc /proc proc defaults 0 0 /dev/VolGroup00/LogVol01 swap swap defaults 0 0 /dev/fd0 /media/floppy auto rw,user,noauto 0 0 fs_manage_fusefs_dirs(hald_t) Thanks for your help
William, I will add "fs_manage_fusefs_dirs(hald_t)" to selinux-policy. You can add this rule for now using # grep avc /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp
Fixed in selinux-policy-3.5.13-62.fc10
This is a new error message as of July 21,09: SELinux is preventing hal-storage-mou (hald_t) "create" to ./.hal-mtab-lock (fusefs_t). The suggested repair fails to clear up the problem restorecon -v './.hal-mtab-lock' Additional Information Source Context: system_u:system_r:hald_t:s0Target Context: system_u:object_r:fusefs_t:s0Target Objects: ./.hal-mtab-lock [ file ]Source: hal-storage-mouSource Path: /usr/libexec/hal-storage-mountPort: <Unknown>Host: localhost.localdomainSource RPM Packages: hal-0.5.12-14.20081027git.fc10Target RPM Packages: Policy RPM: selinux-policy-3.5.13-64.fc10Selinux Enabled: TruePolicy Type: targetedMLS Enabled: TrueEnforcing Mode: EnforcingPlugin Name: catchall_fileHost Name: localhost.localdomainPlatform: Linux localhost.localdomain 2.6.27.25-170.2.72.fc10.i686 #1 SMP Sun Jun 21 19:03:24 EDT 2009 i686 athlonAlert Count: 9First Seen: Sun 12 Jul 2009 02:14:54 PM EDTLast Seen: Sun 12 Jul 2009 02:56:31 PM EDTLocal ID: 8d25bd3f-9a1d-45dd-8290-9e2872b7e86dLine Numbers: Raw Audit Messages :node=localhost.localdomain type=AVC msg=audit(1247424991.487:42): avc: denied { create } for pid=4172 comm="hal-storage-mou" name=".hal-mtab-lock" scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:fusefs_t:s0 tclass=file node=localhost.localdomain type=SYSCALL msg=audit(1247424991.487:42): arch=40000003 syscall=5 success=no exit=-13 a0=804da30 a1=8042 a2=180 a3=8042 items=0 ppid=2204 pid=4172 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="hal-storage-mou" exe="/usr/libexec/hal-storage-mount" subj=system_u:system_r:hald_t:s0 key=(null)
Hal is trying to create a file in a fusefs file system?
Unfortunately, There is no more information that I can provide at this time. The end result of the problem is that same as the problem which was and is that no internal or external drives are auto mounted or dis-mounted! All external drives including USB drives require a root login command line mounting. Very time consuming and annoying when you are in a hurry to get info off of a USB drive.i copied the error message exactly as it was shown through the SELinux trouble shooter application.
After looking into the problem a little more, I don't think that this problem belongs to SELinux. I disabled SELinux and attempted to mount all of my internal and external drives. None of the drives would auto-mount! Also, if I mounted more than one drive at a time, the only drive available would be the last drive mounted, although I would have two icons for differing drives showing on the desktop. I believe that the "create" to ./.hal-mtab-lock error is a symptom of some problem with the haldaemon. for what ever reason as I am not sure, some process, haldaemon maybe, is trying to create the hidden file "create" to ./.hal-mtab-lock but is unable to do so? Do you have any ideas as to how to approach the problem?
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. 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 '10'. 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 10'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 10 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
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.