Description of problem: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Boot to Gnome environment. 2. Start gnome-terminal. 3. Gain root access. 4. Plug in the USB drive. 5. Unmount all auto mounted directories of the USB drive. 6. Remove all parititions in the USB drive using fdisk. 7. Create a new partition in W95 format using all space. 8. Write to partition table. 9. Format the partition using mkfs.vfat. 10. There is a pop up of SELinux Denial on the taskbar. Actual results: The following SELinux Denials: Summary: SELinux is preventing automount (automount_t) "read" to ./core.2350 (root_t). Detailed Description: [SELinux is in permissive mode, the operation would have been denied but was permitted due to permissive mode.] SELinux denied access requested by automount. It is not expected that this access is required by automount and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for ./core.2350, restorecon -v './core.2350' If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Context system_u:system_r:automount_t:s0 Target Context system_u:object_r:root_t:s0 Target Objects ./core.2350 [ file ] Source automount Source Path <Unknown> Port <Unknown> Host castor Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.3.1-28.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Permissive Plugin Name catchall_file Host Name castor Platform Linux castor 2.6.25-0.200.rc8.git3.fc9.i686 #1 SMP Sat Apr 5 00:00:10 EDT 2008 i686 i686 Alert Count 1 First Seen 西元2008年04月07日 (週一) 14時57分12秒 Last Seen 西元2008年04月07日 (週一) 14時57分12秒 Local ID 4dda2971-d0fd-4701-950f-7fafe10b45aa Line Numbers Raw Audit Messages host=castor type=AVC msg=audit(1207544232.188:20): avc: denied { read } for pid=4077 comm="automount" name="core.2350" dev=sda2 ino=97730 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=file Expected results: Mounted with none of the above error. Additional info: This is not happening when user unplug and plug the USB drive again.
Please provide the automount map you have created to access these USB devices and obtain a debug log as described at http://people.redhat.com/jmoyer and post it to the bug.
Created attachment 301469 [details] autofs_stuff as per request.
I didn't use autofs table (auto.master, etc) but it just as the way of automatically mounted by system when USB drive is plugged in.
host=castor type=AVC msg=audit(1207544232.188:20): avc: denied { read } for pid=4077 comm="automount" name="core.2350" dev=sda2 ino=97730 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=file This looks like automount may have dumped core, and selinux may be preventing it from finishing that process. I'm not sure why the act of dumping core would trigger a read, though. Is /core.2350 a valid core file?
What version of autofs are you running?
autofs-5.0.3-11.i386.rpm Wasn't Ian saying this bug might be not related to autofs?
(In reply to comment #9) > autofs-5.0.3-11.i386.rpm > > Wasn't Ian saying this bug might be not related to autofs? I did say that and I still think the actual problem is with hal. But Jeff trying to find out if autofs SEGVed and why. Is the core above an autofs core? Ian
Ahhh, I see we changed the component but left it assigned to Jeff, that's not right. Lets follow through on the core file before passing it on. Ian
So sorry if I confused you guysin previous comments. That's seems to be the only core file I got at /.
(In reply to comment #12) > So sorry if I confused you guysin previous comments. > > That's seems to be the only core file I got at /. It is an automount core file, what was the date stamp on the original file?
2008-04-07
That is a bit odd since you've got the default configuration and it isn't related to what you're doing with the USB devices. It's a big ask but, if you're system hasn't changed much, could you install the autofs-5.0.3-debuginfo-11 package and do: gdb -c /core.2350 /usr/sbin/automount gdb> thr a a bt and post it here please. Assuming the core is still in /, of course. Ian
(In reply to comment #15) > That is a bit odd since you've got the default configuration > and it isn't related to what you're doing with the USB devices. > > It's a big ask but, if you're system hasn't changed much, could > you install the autofs-5.0.3-debuginfo-11 package and do: > > gdb -c /core.2350 /usr/sbin/automount > gdb> thr a a bt > > and post it here please. > Assuming the core is still in /, of course. The point of getting the core was to do this myself, instead of putting that burden on teh reporter. However, I'm not getting very good results, as I don't have a system that matches (different versions of libraries, etc). So, yeah, could you please get us the gdb output, Caius? You can find the debuginfo rpm here: http://koji.fedoraproject.org/packages/autofs/5.0.3/11/i386/autofs-debuginfo-5.0.3-11.i386.rpm Thanks!
It isn't any problem for me to test. Will test during this weekend and get back to you. Rgds.
Created attachment 302257 [details] gdb output Please kindly check and let me know if you want more info. I will keep the core file for a while.
(In reply to comment #18) > Created an attachment (id=302257) [edit] > gdb output > > Please kindly check and let me know if you want more info. I will keep the core > file for a while. This looks like something that I've started seeing on F-8 the last couple of weeks. I don't see a segfault though but I probably should be. Can you re-test with autofs-5.0.3-12 when it gets to the repository please. Ian
If you're interested, the package can be had here as well: http://koji.fedoraproject.org/koji/buildinfo?buildID=46454
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Reporter, could you please reply to the previous question? If you won't reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.
I am sorry that I had been busy since then and there is no resources for me to collect data. Please kindly drop this bug if there are no similar reports on upstream tracker. Thank you very much.
Not in Fedora 10 anymore. Please close this bug.