Bug 244065 - Cannot mount any USB devices from KDE: "Permission denied: Not in active session"
Cannot mount any USB devices from KDE: "Permission denied: Not in active sess...
Product: Fedora
Classification: Fedora
Component: kdebase (Show other bugs)
All Linux
low Severity high
: ---
: ---
Assigned To: Ngo Than
Fedora Extras Quality Assurance
: 244585 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2007-06-13 11:40 EDT by David Anderson
Modified: 2007-11-30 17:12 EST (History)
7 users (show)

See Also:
Fixed In Version: 3.5.7-20.fc7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-08-20 12:03:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
cron.daily/prelink patch (462 bytes, patch)
2007-08-01 20:38 EDT, Sergio Monteiro Basto
no flags Details | Diff

  None (edit)
Description David Anderson 2007-06-13 11:40:52 EDT
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
        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:

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!
Comment 1 David Anderson 2007-06-13 11:41:41 EDT
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
Comment 2 David Anderson 2007-06-13 11:52:04 EDT
Further info: whilst /usr/bin/kio_media_mounthelper gives the above error 
also, /usr/bin/gnome-mount mounts the device with no problems.
Comment 3 Oleg Girko 2007-06-13 19:42:53 EDT
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.
Comment 4 David Anderson 2007-06-13 20:15:12 EDT
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).
Comment 5 Oleg Girko 2007-06-13 20:36:16 EDT
The format of ext3 filesystem didn't change since then, so there's no problem with ACLs on your 

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?
Comment 6 David Anderson 2007-06-14 06:48:26 EDT
Mounting CDs and DVDs works fine for me.
Comment 7 David Anderson 2007-06-14 06:50:12 EDT
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... ;-)
Comment 8 David Zeuthen 2007-06-14 16:24:22 EDT
Changing to kdebase and adding myself as Cc if there are any CK/HAL questions.
Comment 9 David Anderson 2007-06-15 14:56:53 EDT
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.
Comment 10 David Zeuthen 2007-06-19 10:09:08 EDT
*** Bug 244585 has been marked as a duplicate of this bug. ***
Comment 11 Rex Dieter 2007-06-19 10:15:23 EDT
fwiw, my usb stick WORKSFORME (plugin -> automounts).
Comment 12 Oleg Girko 2007-06-19 10:44:46 EDT
Do you have F7 upgraded from FC6? Do you use KDE?
Comment 13 Rex Dieter 2007-06-19 10:49:38 EDT
F7 KDE livecd (clean) install.
Comment 14 Oleg Girko 2007-06-19 11:17:06 EDT
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.
Comment 15 Oleg Girko 2007-06-19 17:18:29 EDT
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.
Comment 16 Oleg Girko 2007-06-19 17:26:55 EDT
Oops, sorry, I was unable to create attachment, but don't worry, the workaround shell script file 
is very short (2 lines):

Comment 17 David Anderson 2007-06-23 17:09:47 EDT
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 

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).
Comment 18 David Anderson 2007-06-23 17:12:55 EDT
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.
Comment 19 redhat-bugs2eran 2007-06-29 23:13:55 EDT
Here too, the problem disappears after setting PRELINKING=yes in
Comment 20 David Anderson 2007-07-02 03:56:37 EDT
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.
Comment 21 Sergio Monteiro Basto 2007-07-26 13:47:21 EDT
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 .

Comment 22 Sergio Monteiro Basto 2007-07-26 13:47:46 EDT
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 .

Comment 23 David Anderson 2007-08-01 09:28:18 EDT
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.
Comment 24 Rex Dieter 2007-08-01 09:51:19 EDT
It could also be that setting PRELINK also indirectly sets KDE_IS_PRELINKED (see

Regardless, still mostly a mystery, since no fedora/kde developer has yet to be
able to reproduce the problem as described.  ):
Comment 25 Sergio Monteiro Basto 2007-08-01 10:04:18 EDT
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
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 ? 
Comment 26 Oleg Girko 2007-08-01 11:55:03 EDT
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 

Reply to comments #24 and #25.
To reproduce the problem, just set "PRELINKING=no" in "/etc/sysconfig/prelink" and reboot.
Comment 27 Rex Dieter 2007-08-01 13:34:56 EDT
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
Comment 28 Sergio Monteiro Basto 2007-08-01 20:38:18 EDT
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 

how about this patch ? to put prelink running again
Comment 29 Sergio Monteiro Basto 2007-08-01 21:13:28 EDT
add /etc/X11/xinit/xinitrc.d/kde.sh with

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 ?   

Comment 30 Rex Dieter 2007-08-03 10:22:49 EDT
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)
Comment 31 Oleg Girko 2007-08-03 10:43:28 EDT
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.
Comment 32 Rex Dieter 2007-08-03 10:47:38 EDT
As far as I'm concerned, you're right, it's out of kde's hands now.
Comment 33 David Zeuthen 2007-08-06 10:58:27 EDT
The so-called "hack" that CK uses to achieve this is the only way to do this
right now without kernel-side support.
Comment 34 David Anderson 2007-08-07 14:33:00 EDT
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).
Comment 35 David Anderson 2007-08-07 14:35:14 EDT
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).
Comment 36 David Zeuthen 2007-08-07 14:54:34 EDT
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.
Comment 37 David Zeuthen 2007-08-13 14:23:46 EDT
Btw, here's the same bug being tracked on OpenSUSE

Comment 39 David Anderson 2007-08-14 08:39:36 EDT
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?
Comment 40 Rex Dieter 2007-08-14 10:07:00 EDT
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)
Comment 41 David Zeuthen 2007-08-14 12:46:35 EDT
(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.
Comment 42 Fedora Update System 2007-08-20 12:03:44 EDT
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.
Comment 43 Dimitris 2007-10-28 11:52:05 EDT
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.
Comment 44 Sergio Monteiro Basto 2007-10-29 01:12:57 EDT
well , this issue was solved by updating system, have you your system updated ?
Comment 45 David Anderson 2007-10-31 12:31:41 EDT
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.

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