Bug 502472

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?

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.