It’s getting boring I know; more ConsoleKit braindumps

Since people insist that I don’t make myself enough verbose on the matter of how pambase gets implemented, here comes another post detailing some of the trouble me and Samuli are going through to make Gentoo a viable modern desktop.

First of all let’s make it clear what the target is: ConsoleKit is the modern implementation of the common necessity to provide different authorisation to users depending on whether they are connected on the local system or connecting from a remote system. The reason why this is useful on desktop systems is that you obviously don’t want somebody from a remote system to access your USB devices or cdroms, or soundcard while not being root.

Interestingly, the idea of this authorisation has always been tied tightly with PAM; the first try to get this working was the RedHat-generated patch that added the infamous pam_console module to Linux-PAM; one of my first problems to solve with Linux-PAM, and one of the first patches to be killed was indeed that which added this module. Unfortunately, the method used by pam_console was a very bad one: it changed the owners of device nodes in /dev, but if a session was abruptly interrupted, then it wouldn’t set them back correctly. Besides, it didn’t work that well when multiple users were logged in on different TTYs.

ConsoleKit handles this in a much different way, even though it still uses (mostly) PAM to do the work. Basically, when you open a new login session (and just login, not authentication for services), the PAM connector connects (sorry) via D-Bus to the daemon to tell it that there is now an open session; as long as that connection is open, the session is listed, and all the processes started from there are authorised. What’s the catch here? Well, to know which session a process belongs to, you have two obvious ways; neither of which is very reliable: you can check the parent process ID (which is not going to be fun when the process detaches into background), or you can check if it has the same open tty (which is not going to work when the program makes not use of ttys at all)., or you can check for the presence of an environment variable, but you will guess it’s a very bland way to solve the problem this latter one.

Luckily, Linux already provides a decent way to identify a session: the /proc/self/sessionid virtual file — but that one needs the kernel to support the Audit framework features. This is the reason why ConsoleKit is now asking you to enable that stuff in the kernel, it’s not just a mood swing, it’s rather a requirement to have proper session isolation. Unfortunately for this to work you also need that each session is created (and destroyed) with login — and we have PAM for that; indeed the module responsible for taking care of that is pam_loginuid that has been added in the latest (non-M4) version of pambase.

The bad side is, though, that it doesn’t help if pambase is fixed, if any other maintainer of a package using PAM is not listening to me (or insist that I shouldn’t dictate the PAM policies even though I’m the only one who seem to have a clue on how things have been asked to be supported for quite a while). This means that we have to fix all the graphical login managers (gdm, kdm, wdm, xdm, entrance, slim, qingy, …) to include the correct service file (system-graphical-login), so that the proper sessions are set up. Not just that, but as we were able to debug with Samuli, we need to fix both baselayout and openrc to use the system-services stack (so finally abiding to pam_mktemp as it was supposed to do since a very long time ago), since otherwise a service started not by the rc system but rather from a running logged-in session would inherit the root’s login session id, which is obviously a bad thing.

This was designed to work correctly with system-services, but as it turns out, unless I actually pay attention to each and every package that should use them, even when I actually coordinate integration of the new services into pambase with them, or I do the original changes myself, the end result is simply bad. This is why an audit is necessary as I said before.

I was intending to end this post with a description of the incompatibilities between Qingy and ConsoleKit, but after writing a few paragraph, I decided that without enough diagrams of what’s going on, there is no way I can actually provide you with a description of it that can be understood by those who haven’t studied PAM and login themselves. So for now I’ll close on this page, and will post during the week the notes on qingy.

But I’ll also have to warn you that for the next weeks I’m quite swamped with finishing the documentation of one job and starting the work on a new one, so the normal Gentoo stuff is going to stay hidden for a while; if you wish to help with testing or motivation it’s certainly appreciated. I’ll see to provide a testing pambase ebuild on the repository itself so that those of you who feel daring enough can get to test it. As a homework for anyone who’s interested, feel free to open bugs about desktop managers in tree and official overlays – with pam-bugs@g.o in CC – if they should be migrated to system-graphical-login once the new pambase is released.