On Tue, 2015-01-20 at 17:56 -0800, Russ Allbery wrote: > > So apparently it's PolicyKit, not ConsoleKit, but still almost certainly > > logind. > > I think that's PolicyKit wanting to use logind for something it previously > used ConsoleKit for, and the changelog for the package seems to back that > up. Sometime, I must really get my head around what these things do. Bits of what follows are almost certainly wrong. Corrections welcomed. My naive understanding is that this PAM dependency & ConsoleKit arise from something that was easier to understand back in the Unix 7 days - the need for your login tty (eg /dev/ttyS1) to be owned by you. When nobody was logged in it was owned by root (typically), and no one could use it. But when it was used to log in something had to chown it to the person who was using so they could send characters to their terminal device, and read whatever key presses happened. And when they logged out it had to be changed by to root, so some malicious student couldn't entertain themselves by forcing the ASR133 teletype to dump it's entire paper roll onto the floor. Back then it was all done by /sbin/login and /sbin/getty. Login changed the ownerships to you before exec'ing the shell, getty changed it back when it was re-spawned after you logged out and life was so, so simple. Part of the problem is PAM. I recall the day I was stunned to find the login didn't just exec the login shell (and hence disappear), but rather hung around for the entire time you were logged in. That would not of been tolerated in the RAM constrained Unix 7 days. Tracing it back, this turned out to be because of the session management PAM provided. Replace "session management" with "change permissions of /dev/ttyS1 on log in, and revert them on logout, and you sort of see how that happened. Given the way PAM works (it's just a C library that lives in some process), it requires whatever process it lived to hang around, watching and waiting for you to log out, and then tell PAM about it. Yes, that added complexity, but in return for that the P in PAM stands for pluggable, and so now it was possible to track all sorts of other things when the user logged in, and undo them when they logged out. Like update utmp and wtmp, and obtain Kerbos tickets. By now I'm sure we have dreamt up things I am not aware of that are tracked between login in logout, so many that we now give that time interval a name - a session. As it turned out PAM absorbed all the functions of the old login program. All that remained for it to do is providing a Linux process PAM could store its data in for the duration of the session, but anything could do that. Login provided that process when someone logged in on a physical terminal, but if some process had to hang around anyway - like sshd or the X display manager, then it could provide it. And that's what happened. So when you use ssh to log in the login program is not used at all - sshd runs the guts of what used to be in login, that is PAM, itself. The next minor complication is as things got more sophisticated it wasn't just /dev/ttyS1 a person logging locally in wanted access to. He wanted access things like the sound card, and the web cam. Maybe even the video card. Good software design principles dictated some central thing had decide he was logged locally and what that gave him access to, and so ConsoleKit was born. ConsoleKit is just another thing can take advantage of the P in PAM. A some point novice users with laptops's came along, and it turns out a person logging might be granted all sorts of other superuser powers as well - like installing packages, starting and stopping network interfaces, managing power consumption. Again we need a single piece of code to manage that - something a GUI interface like synaptic could go and ask for root permissions, and get it, as least for the duration of the session. And so PolicyKit was born. Of course, all these pieces (now often running in independent processes) all needed a way to communicate, and after going through a very painful period of each tool kit (eg, GTK, KDE) providing their own incompatible way, DBus was born. So now we have some wonderful functionality, but implemented in a complex thicket of cross dependencies. (And we haven't covered managing on the fly hardware changes, like USB devices.) It's a mess. Touch one thing and another broke. Everybody hated it. And we kept trying to fix it, so for example on the hardware side we went from HAL to hotplug to udev with devfs fitting somewhere in there. Not surprisingly the maintainers of things like ConsoleKit got the shits and gave up, so we entered a phase with key pieces of our infrastructure being unmaintained. Then along comes systemd, who redoes the entire thing as one tarball so it just works. It's no wonder the Gnome people were glad to wash their hands of it, and just use what systemd provides. That would be udev, ConsoleKit, dbus, and bits of session management like logind. Even better, the systemd mob seem to have remarkably thick skins so we can probably rely on them to keep doing this for a while, despite the enormous amounts of crap we throw at them. There is a catch of course - we get a whole pile of other stuff in that same source tarball, some of which like journald we are forced to run. Yes, it's very likely some DD's will find other bits of candy they provide attractive - and if we aren't locked in now we soon will be. Some may hate this (it does make me twitch), but do try to face facts. In the desktop arena we depend on this stuff, and the systemd gang are the only ones who have stepped up to the plate.
Attachment:
signature.asc
Description: This is a digitally signed message part