How can I activate the current session in ConsoleKit?

Question

I have a live Debian Squeeze system on a USB drive, containing a script I use to image another drive. This script uses udisks to mount a drive by label, but it doesn't work over a serial console. The reason is that the session associated with the serial console does not appear to be "active", which means that udisks fails with:

user@my-live-usb:~$ udisks --mount /dev/disk/by-label/image-data --mount-options ro
Mount failed: Not Authorized

Changing the allow_any key in /usr/share/polkit-1/actions/org.freedesktop.udisks.policy doesn't help, so I'd like to know how to tell ConsoleKit that the serial console is "active". Trying to do this via the DBUS interface fails:

user@my-live-usb:~$ dbus-send --system --print-reply --dest="org.freedesktop.ConsoleKit" /org/freedesktop/ConsoleKit/Session7 org.freedesktop.ConsoleKit.Session.Activate
Error org.freedesktop.DBus.GLib.UnmappedError.CkSeatError.Code0: Unable to activate session

Session7 is the one listed as being on /dev/ttyS0.

So how can I get ConsoleKit to recognise the serial console as an active session?

(In my case, udisks version is 1.0.1+git20100614-3, consolekit is 0.4.1-4.)

It's also probably worth noting the the Debian live system automatically logs the live user in on all 6 video consoles and the serial console.

Answer 1

The objective is to setup an active ConsoleKit session. You can check this via:

$ ck-list-sessions | grep active
    active = TRUE

If there are multiple ConsoleKit sessions only one session at most can be active at a time.

If the output is something like

$ ck-list-sessions | grep active
    active = FALSE
    active = FALSE

you have a problem because things that need an active ConsoleKit session to authenticate for sending messages over dbus do not work (e.g. NetworkManager, i.e. nm-applet, udisk ...).

There are several methods to create (and activate) a ConsoleKit session. The display manager may setup one via directly communicating with the ConsoleKit daemon. Or a pam-module may do it. Or a login/X11-session-init script might call ck-launch-session which should create an active session (modulo bugs).

Usually, the goal should be to setup ConsoleKit in such a way that you get an active session for your window manager or login shell (not just for single scripts).

To test the ConsoleKit system you can try to use ck-launch-session to create a proper consolekit session. For example you can call your script like this:

$ ck-launch-session ./script

To test if ck-launch-session is bug-free you can call

$ ck-launch-session ck-list-sessions

and check if there is an active session.

Bugs: Updates to the ConsoleKit system recently introduced various bugs into the fragile (and over-engineered?) ConsoleKit ecosystem.

For example on my Ubuntu 11.10 system I had to delete nox11 from the pam_ck_connector.so line in /etc/pam.d/common-session after ck-launch-session stopped working after a system upgrade:

--- a/pam.d/common-session      Fri May 25 10:26:53 2012 +0200
+++ b/pam.d/common-session      Fri May 25 10:39:41 2012 +0200
@@ -29,5 +29,5 @@
 session        required        pam_unix.so 
 session        optional                        pam_winbind.so 
 session        optional        pam_ecryptfs.so unwrap
-session        optional                        pam_ck_connector.so nox11
+session        optional                        pam_ck_connector.so
 # end of pam-auth-update config

With that change now I directly get an active session when starting my window manager via WDM login.

That means that the window manager now runs inside an active ConsoleKit session and everything that is started as a child from the window manager process (e.g. from an xterm) is also part of that session, i.e. no need for extra calls of ck-launch-session for e.g. nm-applet any more.

Answer 2

I had a problem with session, where is-local and active was FALSE. /bin/login used pam_ck_connector to make a proper session. Then I executed xinit with ck-launch-session openbox in ~/.xinitrc. The second session was broken.

The solution is NOT to use ck-launch-session, but execute xinit staying on the same virtual terminal and keeping the existing first local session active: XINITRC=/path_to_custom/xinitrc xinit -- :1 vt1