ConsoleKit – Shut Down System via ConsoleKit DBus Message as User

ConsoleKit (documentation) was a service which tracks user sessions (i.e. where a user is logged in). It allows switching users without logging out (many users can be logged in on the same hardware at the same time with one user active). It is also used to check if a session is "local" i.e. if a user has direct access to hardware (which may be considered more secure than remote access).

Currently the ConsoleKit is largely replaced by logind, which is part of systemd, although there is standalone version elogind.

polkit (née PolicyKit) documentation allows fine-tuned capabilities in a desktop environment. Traditionally only a privileged user (root) was allowed to configure network. However, while in a server environment it is a reasonable assumption that it would be too limiting to not be allowed to connect to a hotspot on laptop, for example. However, you may still not want to give full privileges to this person (like installing programs) or may want to limit options for some people (for example on your children laptops only 'trusted' networks with parental filters can be used). As far as I remember it works like:

• Program send message to daemon via dbus about action
• Daemon uses polkit libraries/configuration (in fact polkit daemon) to determine if a user is allowed to perform an action. It may happen that certain conditions must be fulfilled (like entering password or hardware access).
• Daemon performs action according to it (returns auth error or performs action)

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.