Bug 248687 - umounting hal mounted media with umount does not work, works with umount.hal
umounting hal mounted media with umount does not work, works with umount.hal
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Daniel Walsh
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-07-18 05:10 EDT by Thorsten Leemhuis
Modified: 2007-11-30 17:12 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-09-18 13:36:38 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
strace from umount.hal when chain called from /bin/umount (7.85 KB, application/octet-stream)
2007-07-20 09:43 EDT, Thorsten Leemhuis
no flags Details

  None (edit)
Description Thorsten Leemhuis 2007-07-18 05:10:08 EDT
Description of problem:
Umount afaics call umount.hal to umount hal-mounted media. That seems to fail
for some strange reason and umounting fails

Version-Release number of selected component (if applicable):
util-linux-2.13-0.52.fc7

How reproducible:
Always

Steps to Reproduce:
[thl@thl ~]$ # /me puts a CD into the drive an waits for hal to mount it.
[thl@thl ~]$ mount | grep Neu
/dev/scd0 on /media/Neu type iso9660 (ro,nosuid,nodev,uhelper=hal,uid=2261)
[thl@thl ~]$ gerp Neu /etc/mtab 
bash: gerp: command not found
[thl@thl ~]$ grep Neu /etc/mtab 
/dev/scd0 /media/Neu iso9660 ro,nosuid,nodev,uhelper=hal,uid=2261 0 0
[thl@thl ~]$ umount /media/Neu
/sbin/umount.hal: Unmounting /media/Neu failed:
org.freedesktop.Hal.PermissionDenied: Permission denied: Not in active session
[thl@thl ~]$ /sbin/umount.hal /media/Neu
[thl@thl ~]$
Comment 1 David Zeuthen 2007-07-18 11:24:58 EDT
Did you mess around with the environment or log out of your session? Did you log
in via gdm? What is the content of XDG_SESSION_COOKIE from the shell you're
attempting to do this from?
Comment 2 Thorsten Leemhuis 2007-07-19 00:57:28 EDT
(In reply to comment #1)
> Did you mess around with the environment or log out of your session?

Nope.

> Did you log in via gdm?

Yes.

> What is the content of XDG_SESSION_COOKIE from the shell you're
> attempting to do this from?

$ echo $XDG_SESSION_COOKIE
83de36c13101876e24d369004577e900-1184129730.490865-1030612696

----
Your questions head into a direction as if there would be problems with the
ConsoleKit setup. But wouldn't /sbin/umount.hal fail in that case? But it and
umounting via nautilus work fine; it seems to be more /bin/umount that fails
when it calls /sbin/umount.hal afaics (BTW, that's the reason why I filed the
bug against util-linux and not gnome-mount)

Note that I've seen this error on my main machine, which isn't a isn't a fresh
install; it was updated several times already. But I can reproduce the behavior
on a fresh Fedora 7 install (both machines are x86_64, in case that matters; no
i386 F7 at hand to test atm; sorry)
Comment 3 David Zeuthen 2007-07-19 11:53:32 EDT
(In reply to comment #2)
> Your questions head into a direction as if there would be problems with the
> ConsoleKit setup. But wouldn't /sbin/umount.hal fail in that case? But it and
> umounting via nautilus work fine; it seems to be more /bin/umount that fails
> when it calls /sbin/umount.hal afaics (BTW, that's the reason why I filed the
> bug against util-linux and not gnome-mount)
> 
> Note that I've seen this error on my main machine, which isn't a isn't a fresh
> install; it was updated several times already. But I can reproduce the behavior
> on a fresh Fedora 7 install (both machines are x86_64, in case that matters; no
> i386 F7 at hand to test atm; sorry)

Is it possible you can replace /sbin/umount.hal with a shell script that just
dumps the environment somewhere? And then paste the output as an attachment?
Maybe /bin/umount is deleting something in the environment... Just a guess. Thanks.
Comment 4 Thorsten Leemhuis 2007-07-20 09:43:34 EDT
Created attachment 159654 [details]
strace from umount.hal when chain called from /bin/umount

selinux seems to be the culprit; disabling it temporary solved the problem.
Sorry, should have tried this earlier. No, I can't see any error messages in
audit.log

Find attached a straced run of the original umount.hal when failing (I put a
script in between to catch it)
Comment 5 David Zeuthen 2007-07-20 10:45:45 EDT
Reassigning to selinux-policy-targeted then.
Comment 6 Daniel Walsh 2007-09-10 10:36:30 EDT
Are  you seeing avc messages?
Comment 7 Thorsten Leemhuis 2007-09-13 13:12:21 EDT
(In reply to comment #6)
> Are  you seeing avc messages?

Daniel, no, sorry, there were none on F7 (see comment 4) and are none on rawhide
-- i just re-checked again there.
Comment 8 Daniel Walsh 2007-09-13 16:35:59 EDT
Can you try 

# semodule -DB
to disable dontaudits and then try again.

#semodule -B 

will restore dontaudit rules.
Comment 9 Thorsten Leemhuis 2007-09-14 10:17:32 EDT
what the ... -- it suddenly works now on devel. I got a new
selinux-policy-targeted in the past 24 hours -- Dan, did you change anything?

I can retry on F7 on Monday -- I saw the problem there as well. 
Comment 10 Daniel Walsh 2007-09-14 11:20:34 EDT
Not that I remember. 

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