Why consolekit?

Gullible Jones · 2011-05-22 04:26:24

I keep seeing stuff like this:

Thunar wrote:

Failed to mount "Foo Backup CD"
Not authorized

This is because consolekit doesn't like being launched from the command line. ck-launch-session appears to be broken... again. The alternative is to edit some polkit XML file in /usr, which will be overwritten next time I update; or to use a login manager, which I don't want to do. So much for customizability.

But this makes me wonder. Why the heck are we using Consolekit at all? We have groups for this sort of thing. This is what groups were designed for. Why not use them, instead of having users run some dubious daemon to get the privileges they need for mounting drives and stuff? I cannot make any sense of it.

Is it more secure somehow? It doesn't seem like it ought to be. It looks like any user who runs consolekit can mount drives and stuff with the default configurations, assuming consolekit decides to work. Maybe there are ways of changing this via the XML files? With the polkit-editor thingy perhaps? Does anyone care? Is there actually a good rationale for all of this?

Last edited by Gullible Jones (2011-05-22 04:26:46)

falconindy · 2011-05-22 04:34:54

In short, the goal of ConsoleKit is to give elevated, but controlled, privileges to the person sitting at the physical computer.

Also, works just fine here in dwm, launched with startx.

bohoomil · 2011-05-22 07:51:23

I removed ConsoleKit together with a plethora of other apps (including polkit) about 6 months ago, and never noticed any loss of functionality. I often use external drives and udev is all I need to get them mounted automatically without any fuss. However, my setup is fairly simple and no major application depends on CK, but technically it is possible to live without it just fine.

skottish · 2011-05-22 13:53:26

There seems to be some edge cases where consolekit doesn't work properly and that may be what Gullible is seeing. For instance, I wanted to check out devmon and udisks yesterday and all I get is the 'Not Authorized' message. I got all the way down to the editing polkit files section on the website until I stopped. This hassle is why I dropped polkit and set up udev rules in the first place.

Last edited by skottish (2011-05-22 13:53:40)

falconindy · 2011-05-22 13:59:42

So, fwiw, I used to have this problem as well until I realized it was an order of execution... I had terminals starting before my dbus session was created. Any new terminals created after starting DWM were authorized, as they were able to find the address of the session bus (properly inheriting from the environment).

Last line of .xinitrc:

exec ck-launch-session dbus-launch --sh-syntax --exit-with-session ~/bin/startdwm

And all my apps (read: urxvt) which might conceivably need consolekit access are started in ~/bin/startdwm. Make sure that $DBUS_SESSION_BUS_ADDRESS is set properly, or else this is guaranteed to fail.

the_isz · 2011-05-23 07:57:30

falconindy wrote:

So, fwiw, I used to have this problem as well until I realized it was an order of execution... I had terminals starting before my dbus session was created. Any new terminals created after starting DWM were authorized, as they were able to find the address of the session bus (properly inheriting from the environment).
Last line of .xinitrc:
exec ck-launch-session dbus-launch --sh-syntax --exit-with-session ~/bin/startdwm
And all my apps (read: urxvt) which might conceivably need consolekit access are started in ~/bin/startdwm. Make sure that $DBUS_SESSION_BUS_ADDRESS is set properly, or else this is guaranteed to fail.

You might want to mention that this recipe isn't working in all cases. If you're
using a login manager, then it is the login manager's responsibility to issue
the ck-launch-session command. Otherwise, you'll get into trouble. To see if you
already are, you can check out the output of the ck-list-sessions command. If
you're seeing multiple sessions, non-local or non-active sessions, you haven't
initialized consolekit properly and are likely to run into trouble with
applications using consolekit.

So, unless you're starting X directly (i.e. via 'startx' from command line), the
ck-launch-session command must not be in your .xinitc.

As to adding dbus-launch to your .xinitrc: The preferred method to do this is
explained in 'man dbus-launch', pretty much at the top. The way you do it is OK,
but the creators of dbus-launch recommend otherwise, but that's just a FYI.

Hope I could help a bit, I was going through trouble with consolekit, too.

Gullible Jones · 2011-05-23 23:45:13

Hmm, interesting. Thanks for the info. I didn't realize that Consolekit differentiated between local and remote users.

Just for what it's worth - some distros (Zenwalk for instance) seem to invoke Consolekit as root during boot up, which appears to make everything just work. The session continues to run as root while you use the desktop, and ck-list-sessions looks like this:

Session1:
    unix-user = '1000'
    realname = '(null)'
    seat = 'Seat1'
    session-type = ''
    active = TRUE
    x11-display = ':0'
    x11-display-device = '/dev/tty7'
    display-device = ''
    remote-host-name = ''
    is-local = TRUE
    on-since = '2011-05-24T18:35:01.031469Z'
    login-session-id = ''

Is this possible to do on Arch, or does it need special configuration? More importantly, is it wise to do on Arch? Would it make all sessions equivalent to local sessions?

Edit: Dunno about the security, but the answer is, it is possible... Kind of. If you start console-kit-daemon as root while in an X session, everything works! But if you have it started as root from rc.local, it doesn't work at all, and I have no idea why. I'll have to experiment more with this.

Edit again: For the record, invoking ck-launch-session before dbus-launch in /etc/X11/xinit/xinitrc.d/30-dbus makes everything work fine. Perhaps this should be done by default?

Last edited by Gullible Jones (2011-05-24 02:54:16)

ConnorBehan · 2011-05-24 03:50:44

Gullible Jones wrote:

But this makes me wonder. Why the heck are we using Consolekit at all? We have groups for this sort of thing. This is what groups were designed for. Why not use them, instead of having users run some dubious daemon to get the privileges they need for mounting drives and stuff? I cannot make any sense of it.

This may not contribute any new information but I completely agree with you.

[root@connors-laptop ~]# pacman -Q | grep kit
libwebkit 1.4.0-1
silc-toolkit 1.1.10-1

Gullible Jones · 2011-05-24 04:06:05

Err yeah, this is getting very strange. Starting Consolekit via /etc/X11/xinit/xinitrc.d/30-dbus, as I described, makes volume handling work; but doesn't do anything for power management. Whereas starting it with .xinitrc makes power management work, but not volume management.

Surely there must be some solution for people who want to start X from the command line, instead of using a bloaty login manager?

Arch Linux

#1 2011-05-22 04:26:24

Why consolekit?

#2 2011-05-22 04:34:54

Re: Why consolekit?

#3 2011-05-22 07:51:23

Re: Why consolekit?

#4 2011-05-22 13:53:26

Re: Why consolekit?

#5 2011-05-22 13:59:42

Re: Why consolekit?

#6 2011-05-23 07:57:30

Re: Why consolekit?

#7 2011-05-23 23:45:13

Re: Why consolekit?

#8 2011-05-24 03:50:44

Re: Why consolekit?

#9 2011-05-24 04:06:05

Re: Why consolekit?

Board footer