Bug 502472 - Prevents the mounting of internal and external drives
Prevents the mounting of internal and external drives
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: hal (Show other bugs)
10
All Linux
low Severity medium
: ---
: ---
Assigned To: Richard Hughes
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-25 08:06 EDT by William Henry
Modified: 2009-12-18 04:29 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-18 04:29:13 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description William Henry 2009-05-25 08:06:46 EDT
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
Comment 1 Daniel Walsh 2009-05-26 08:51:20 EDT
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
Comment 2 William Henry 2009-05-26 19:31:48 EDT
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?
Comment 3 William Henry 2009-05-26 22:31:43 EDT
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
Comment 4 Daniel Walsh 2009-05-27 07:02:18 EDT
Miroslav add

fs_manage_fusefs_dirs(hald_t)
Comment 5 William Henry 2009-05-27 21:13:37 EDT
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
Comment 6 Miroslav Grepl 2009-05-28 08:52:26 EDT
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
Comment 7 Miroslav Grepl 2009-06-03 04:49:43 EDT
Fixed in selinux-policy-3.5.13-62.fc10
Comment 8 William Henry 2009-07-21 11:42:15 EDT
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)
Comment 9 Daniel Walsh 2009-07-21 15:50:07 EDT
Hal is trying to create a file in a fusefs file system?
Comment 10 William Henry 2009-07-21 22:29:49 EDT
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.
Comment 11 William Henry 2009-07-22 21:30:48 EDT
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?
Comment 12 William Henry 2009-07-22 21:31:29 EDT
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?
Comment 13 Bug Zapper 2009-11-18 07:01:38 EST
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
Comment 14 Bug Zapper 2009-12-18 04:29:13 EST
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.

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