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.
Best Answer
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: