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.