Description of problem: I just updated to Fedora 7. When I insert my USB stick and/or hard drive, KDE offers to mount them - which is the desired behaviour. However, on attempting to do so, it gives me the error: "Permission denied: Not in active session". There is only one user on this machine, and only one session active (the machine boots straight into KDE via gdm and auto-login). Version-Release number of selected component (if applicable): ConsoleKit-0.2.1-2.fc7 hal-0.5.9-8.fc7 dbus-1.0.2-4.fc7 [root@shed ~]# /sbin/service ConsoleKit status console-kit-daemon (pid 1769) is running... [root@shed ~]# ck-list-sessions Session1: uid = '500' realname = '' seat = 'Seat1' session-type = '' active = TRUE x11-display = ':0' x11-display-device = '/dev/tty7' display-device = '' remote-host-name = '' is-local = TRUE on-since = '2007-06-13T12:28:18Z' [root@shed ~]# How reproducible: Every time Steps to Reproduce: 1. Insert removable USB media 2. KDE offers to mount / open window. Accept. Actual results: Permission denied: Not in active session Expected results: Mounts! Additional info: This is a laptop, at which I am physically sat. No network involved. I don't understand the point of ConsoleKit; it seems to want to deny me from using hardware on a different session to my own. This seems more like a bug than a feature; if I'm logged in on two different sessions, then I might WANT to be able to use the hardware from one on the other - why does ConsoleKit want to stop me??? If I've authenticated myself on both sessions, why should I be prevented? This is quite aside from this bug, in which CK denies me even though there's only one session!
Forgot to add this to show that I own /dev/console: [root@shed ~]# ll /dev/console crw------- 1 david root 5, 1 2007-06-13 13:28 /dev/console
Further info: whilst /usr/bin/kio_media_mounthelper gives the above error also, /usr/bin/gnome-mount mounts the device with no problems.
Do you have fresh F7 installation or upgraded FC6? I have the same symptoms with upgraded FC6, but it works fine with freshly installed F7.
Upgraded FC6 (began as FC2; has had every version except FC3). I think back when the machine was installed with FC2, the ext3 filesystem didn't support ACLs. I wonder if that has something to do with it? (I read somewhere that ConsoleKit uses ACLs).
The format of ext3 filesystem didn't change since then, so there's no problem with ACLs on your system. Anyway, gnome-mount works, so I presume that hald and ConsoleKit work correctly, and the problem is with the way kio_media_mounthelper requests hald to mount block devices on upgraded FC6. Hence, I propose to change the "Component" field to "kdebase". Another useful observation: I have trouble mounting all block devices: SD and CF cards (using USB cardreader) and even DVD (using SATA DVD drive). Can you mount CD or DVD?
Mounting CDs and DVDs works fine for me.
Would the fact that mounting CDs/DVDs works indicates that the problem could be in HAL/ConsoleKit rather than in KDE? I'm a bit worried that if the bug gets moved to kdebase, it won't get much attention... I'm not saying that Fedora doesn't have a good track record with KDE, but... ;-)
Changing to kdebase and adding myself as Cc if there are any CK/HAL questions. Thanks.
To confirm, this works for me on a fresh installation of F7. That fresh installation was with a home directory copied over from an old installation. The fresh installation (working) has SELinux enabled; the upgrade from FC2 (via 4,5,6) has SELinux disabled.
*** Bug 244585 has been marked as a duplicate of this bug. ***
fwiw, my usb stick WORKSFORME (plugin -> automounts).
Do you have F7 upgraded from FC6? Do you use KDE?
F7 KDE livecd (clean) install.
That's the point of this bug report: mounting block devices works with fresh F7 installation and works with Gnome. It does not work with F7 upgraded from FC6 with KDE.
OK, I've found the cause of the problem: KDE applications launched by loading libraries dynamically into kdeinit (instead of using exec system call) have externally-visible environment ("/proc/$PID/environ") badly screwed up. This usually happens if shared library prelinking is turned off. The chain of interactions looks like this. The kio_media_mounthelper utility sends DCOP request to kded, which in turn sends DBus call to hald which in turn sends DBus request to console-kit-daemon asking which session calling process (kded this time) belongs to. Unfortunately, console-kit-daemon finds session cookie by PID the very brutish way: it extracts XDG_SESSION_COOKIE environment variable right from "/proc/$PID/environ" file. In some cases (see below) kded is launched by dynamically loading kded.so into kdeinit program, which results in bad corruption of "/proc/$PID/environ" (where $PID is the kded's process id). As the result, console-kit-daemon does not find that kded belongs to user's session and refuses to mount the device. The best solution for this problem is to fix kdeinit to not corrupt externally visible environment or to fix ConsoleKit to use less intrusive way to discover the session process belongs to. However, until this solution is implemented workarounds can be used. In order to make kdeinit to use exec() system call instead of dynamic library loading, KDE_IS_PRELINKED environment variable must be set. This can be done using the following methods. 1. Turn on prelinking of shared libraries: install "prelink" package, change PRELINKING variable to "yes" in "/etc/sysconfig/prelink" file. 2. If you don't want to turn prelinking on, just set KDE_IS_PRELINKED variable somewhere else. Just place a simple shell script which sets this variable into "/etc/X11/xinit/xinitrc.d" directory with the name ending with ".sh". Don't forget to make it executable. The example script is attached below. The main disadvantage of these workarounds is slight increase of KDE applications startup time. The fact that Fedora 7 is installed or upgraded from Fedora 6 does not directly affect the cause of the problem, but it correlates significantly. I don't remember exactly when prelinking was introduced first, but systems upgraded from pre-prelinking times don't have prelinking turned on by default. Having prelinking turned off allows kdeinit to use shared library loading to start applications, which triggers this bug.
Oops, sorry, I was unable to create attachment, but don't worry, the workaround shell script file is very short (2 lines): #!/bin/sh [ -z "$KDE_IS_PRELINKED" ] && KDE_IS_PRELINKED=1 && export KDE_IS_PRELINKED
Is it possible to configure ConsoleKit to not care about whether the user is in the active session? i.e. to just care if the user has an active session at all? That's all I care about... if user "david" is trying to mount the device, and the active session is owned by "david", that should be enough; I don't care which session I'm trying to access it from! (I don't understand the rationale for Console Kit denying me access to my own stuff in this way in any case).
Mmmm, possibly the last comment was gibberish. Instead, how about this... if the process calling ConsoleKit is of the same UID as the UID of what CK considers "the active session", then that ought to be enough. UID ought to be the authentication barrier, not session.
Here too, the problem disappears after setting PRELINKING=yes in /etc/sysconfig/prelink.
Shouldn't this bug be moved back to "ConsoleKit"? If ConsoleKit relies upon prelinking and doesn't work without it, I think that's ConsoleKit's problem, not KDE's.
I had this problem with mount and umount my cd and dvds , I had this problem with kde i386 and don't have it on my computer in home . I use kde by default , both computers had been upgraded from FC6 and I had SELINUX disabled .
I had this problem with mount and umount my cd and dvds , I had this problem with kde i386 and don't have it on my computer in home with x86_64. I use kde by default , both computers had been upgraded from FC6 and I had SELINUX disabled .
Can anyone comment on why this bug hasn't been re-assigned to ConsoleKit rather than kdelibs? ConsoleKit is making a mistaken assumption; that's surely its bug rather than kde's. I can confirm that the problem disappeared for me too when setting the environment variable mentioned above.
It could also be that setting PRELINK also indirectly sets KDE_IS_PRELINKED (see /etc/profile.d/kde.sh). Regardless, still mostly a mystery, since no fedora/kde developer has yet to be able to reproduce the problem as described. ):
well , think I am getting into the problem cat /var/log/prelink/prelink.log cat: /var/log/prelink/prelink.log: No such file or directory cat /var/lib/misc/prelink.force (none) cat /var/lib/misc/prelink.full Fri May 19 14:51:03 WEST 2006 so no prelink neither run /etc/cron.daily/prelink does anything any suggestions ?
Reply to comment #23. I agree that this bug belongs to ConsoleKit, because it wrongly assumes that "/proc/$PID/environ" contains meaningful information. Reply to comment #24. Please read my comments #15 and #16 where I explain the _real_ cause of the problem. Yes, turning off prelinking itself is not a problem. The problem is that turning off prelinking allows kdeinit to launch programs by loading libraries dynamically instead of making exec() system call. The way kdeinit sets environment to be used by loaded library makes "/proc/$PID/environ" to contain garbage. This completely confuses ConsoleKit, because it tries to find session cookie there. Reply to comments #24 and #25. To reproduce the problem, just set "PRELINKING=no" in "/etc/sysconfig/prelink" and reboot.
Oleg, thanks for the concise summary. I think I get it now. Looks like a quick-n-dirty solution for most folks is to set KDE_IS_PRELINKED regardless if system-wide prelinking is enabled or not (Than, any objections?) But as far a ConsoleKit is concerned, this is/will-be an ongoing problem when used with kde. (There exist a few similar issues wrt selinux for the same reasons). David, any insight/suggestions other than "make kde avoid kdeinit as much as possible"?
Created attachment 160483 [details] cron.daily/prelink patch (In reply to comment #26) > Reply to comments #24 and #25. > To reproduce the problem, just set "PRELINKING=no" in "/etc/sysconfig/prelink" and reboot. I got the problem "Permission denied: Not in active session" , I still don't solve it , I just realize that I had prelink stopped since I had upgrade to f7 on my laptop. Now I see that I don't have KDE_IS_PRELINKED on env how about this patch ? to put prelink running again
add /etc/X11/xinit/xinitrc.d/kde.sh with #!/bin/sh [ -z "$KDE_IS_PRELINKED" ] && KDE_IS_PRELINKED=1 && export KDE_IS_PRELINKED do the trick thanks, but just after run successfully prelink ! I remember done the trick before runnig prelink and didn't worked . At last should I open a bug about : after upgrade from fc6 to f7 , prelink stops to work ?
kdelibs changelog: * Fri Aug 03 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 6:3.5.7-16 - set KDE_IS_PRELINKED unconditionally (#244065) fyi, KDE_IS_PRELINKED is set in /etc/profile.d/kde.(csh|sh)
OK, great. This is good as a temporary workaround, but it introduces a regression: inability of kdeinit to use dynamic library loading optimisation even with prelinking turned off. My opinion is that logic of ConsoleKit must be changed to not use false assumption about contents of "/proc/$PID/environ". User applications must provide credentials (like session cookie) inside DBus calls when mounting media and performing other privileged tasks instead of using hacks like letting DBus services to look into internal process data to get credentials out of band. I think that this bug must be assigned back to ConsoleKit.
As far as I'm concerned, you're right, it's out of kde's hands now.
The so-called "hack" that CK uses to achieve this is the only way to do this right now without kernel-side support.
David Z: I notice you've reassigned this to kdebase... can you explain why this bug should be assigned to kdebase? Commenter #31 is saying that CK is relying on an unreliable method; you seem to agree; if it's correct that this is the only possible way without kernel support, then wouldn't the correct solution be to not activate CK on Fedora until that support is available? It seems somewhat rude of CK to disable KDE - KDE was there first, and isn't breaking any rules; CK seems to be adding a new requirement (that processes don't alter their own environments) and seems to have been deployed prematurely without patches being added to its users to make them work (other than Gnome, I presume).
I think it would also be worth considering patching ConsoleKit to deal with the trivial case I've outlined in the bug. If there is only one user session active (which ConsoleKit agrees), and if CK is called by a process with the same UID as the same user session, then CK shouldn't be coming back with "not in user session". If there's only one session and the calling process has the correct UID, then surely that's enough proof that it's in the correct session? That would fix this problem for most users (everyone with a single seat).
No, I don't agree what CK is doing is unreliable; it's a perfectly good assumption to make that processes in a desktop session all descent from a process launched by the login manager. Yes, It would be better to get kernel level support for tagging these processes with a token instead of relying on environment variables. The only real difference between these approaches is that processes can opt out of session membership by clearing the environment and then forking. And that's fine. Comment 15 says: > The best solution for this problem is to fix kdeinit to not corrupt > externally visible environment or to fix ConsoleKit to use less intrusive > way to discover the session process belongs to. As I explained the latter requires kernel-side support so it's not going to happen. As all processes in KDE does originate from the login manager process (where the env variable $XDG_SESSION_COOKIE is indeed set) just fix the bug where your environment is corrupted. You want to do that _anyway_ since other environment variables set by the display manager and/or system-wide scripts may be useful in the session. (For example, in GNOME's display manager we set some environment variables if accessibility was enabled via the display manager. This is to enable the same AT's in the desktop session too. Oh, and of course, things like $LANG etc.) Hope this clarifies.
Btw, here's the same bug being tracked on OpenSUSE https://bugzilla.novell.com/show_bug.cgi?id=298943
The bugfix is here: http://websvn.kde.org/branches/KDE/3.5/kdelibs/kinit/setproctitle.cpp?r1=438982&r2=698691
One other thing I don't understand is that ConsoleKit is using an environment variable as a security token to distinguish one session from another even when those sessions have the same UID. But if they have the same UID, then they can read each other's environment anyway without needing any co-operation from each other, and fool thus ConsoleKit. Have I got this right?
Thanks Kay, patch (from comment #38) applied in rawhide. * Tue Aug 14 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 6:3.5.7-19 - ConsoleKit-related patch (#244065)
(In reply to comment #39) > One other thing I don't understand is that ConsoleKit is using an environment > variable as a security token to distinguish one session from another even when > those sessions have the same UID. But if they have the same UID, then they can > read each other's environment anyway without needing any co-operation from > each other, and fool thus ConsoleKit. Have I got this right? This is off-topic but the answer is this: You are correct that a process with UID X can attach to a session owned by UID X by reading $XDG_SESSION_COOKIE from one of the processes in the session, set XDG_SESSION_COOKIE in his own environment and then fork(). In some future when and if the mechanism for defining session membership is changed from using $XDG_SESSION_COOKIE to using a kernel-enforced token, it won't be possible to transition one process from one session to another for the same user. Either way, since the UID is in fact the same you don't win anything by doing this and there are more interesting ways of sabotaging a session if you got a process running with the same UID (say, simply kill all processes in the session). There is simply nothing to gain assuming the classical UNIX DAC security model. So why $XDG_SESSION_COOKIE? Simply because it allows us refuse service to e.g. inactive session. Indulge me: traditionally a desktop environment contains a power management daemon that is configured to put the system to sleep (suspend) after e.g. 15 minutes of inactivity. Say you have two sessions running with fast-user-switching and the same UID (highly construed example btw). The inactive session (e.g. the one that not being shown on the screen) have now been idle for, say, 15 minutes because the other session is being used. Now, the power management daemon in the inactive session now tries to suspend the system. Without a well-defined session membership (e.g. $XDG_SESSION_COOKIE) we cannot make distinction between the two power management daemons instances; we simply don't know if the request to suspend the system originates from the active or from the inactive session. There's a bunch of other interesting use cases too in which it's useful to have the concept of a session. Hope this clarifies.
kdelibs-3.5.7-20.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.
Unfortunately, i'm having the same problem under GNOME. I already have prelinking enabled and even executed the /etc/cron.daily/prelink by hand, nothing helped. Any help would be appreciated.
well , this issue was solved by updating system, have you your system updated ?
Dimitris: I'd recommend opening a new bug for your problem, as it's likely something different. The issue in this bug was highly KDE specific so you'll be having a different problem.