Re: Systemd

[Russ Allbery <rra@debian.org>]

Russell Stuart <russell-debian@stuart.id.au> writes:

> Sometime, I must really get my head around what these things do.  Bits
> of what follows are almost certainly wrong. Corrections welcomed.

[...]

> 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.

Yup, this is basically correct.

One of my former coworkers (Roland Schemers) who did parts of my job at
Stanford before I did went from Stanford to Sun and, while at Sun, was
responsible for part of the original PAM specification and design.  A lot
of that was motivated by the problems that we had at Stanford, so I'm
rather familiar with the initial impetus.

Back in the day, various programs like telnetd actually invoked login to
do all that tty handling, utmp handling, and so forth.  That was how the
code was shared.  But Kerberos support required doing something's
differently (like password management), and a lot of other things (like
Kerberos ticket cache management).  So Kerberos implementations started
shipping their own login program, but that meant that they had to
reimplement everything that login did, including a bunch of stuff
unrelated to Kerberos itself, like getting all of the device ownership
changes right on different platforms.

This was back in the days when we were running seven different versions of
UNIX at Stanford (NeXTSTEP, SunOS, ULTRIX, AIX, and then later IRIX,
Solaris, OSF/1 nee Digital UNIX nee Tru64, HP-UX, and then, even later,
Linux).  Some of them supported utmp, some utmpx, some had other random
stuff.  Sometimes there was wtmp.  The console devices changed all the
time.  Sometimes there was an /etc/securetty and sometimes there wasn't.
And the Kerberos login program had to work on all of those.  Furthermore,
we wanted to replace /bin/login (as did many other Kerberos sites), since
we wanted to do Kerberos authentication for console login as well.

And we *did* replace /bin/login for years and years, and maintained all
that stuff.  It was a terrifying mass of #ifdef spaghetti.  Roland had to
maintain that code for Stanford and had lots of experience with it, and I
know that was a significant driver behind how PAM works.  The goal was to
let people plug in various login behavior without having to reimplement
all of that crap.  And sessions were in there from the start, since it's
important with Kerberos to both create the ticket cache and then delete it
when the person logs out.

> 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.

Right.  Basically, the problem with UNIX groups, and to an extent the
problem with all the existing PAM modules (with a few exceptions), is that
they grant access based on who the user is.  The problem for this stuff --
the clearest and most obvious example is granting direct write access to
the video card without making the X server setuid root, which is the way
this was generally done in the past -- is that it's not granting access
based on who the user is, but rather *where* the user is.  Anyone who can
log on to console (and figuring out what "console" is provides its own
puzzle) should have access to certain devices, but only while logged on to
console.

And yes, this stuff is still quite important.  Yes, computer labs are
still a thing, and yes, there really are still multiuser computers.
(Saying this only because I've seen people claim this is all obsolete
since people only use their own laptops and should just be added to all
the groups on them.)

Again, here, I've been doing this stuff for long enough that I know what
it was like prior to PAM, let alone prior to ConsoleKit, and I can
describe that in two words: setuid and setgid.  Tons of programs that, in
retrospect, you did not want to trust with elevated privileges were setuid
or setgid just so that they could write to various devices that the person
on console should have access to.  Which created another security
nightmare of its own, since writing a secure setuid program is definitely
way over in the "advanced UNIX skill" spectrum of programming ability.

> 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.

I think this is right, but the PolicyKit part of this is the bit that I'm
much weaker on.

> 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.

After several false starts, IIRC.

> 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, specifically, ConsoleKit was not a great implementation of this
concept.  People found it irritating to work with, it had bugs, and it
didn't handle some of the really interesting problems in this space.  One
of the big ones is multiseat: a computer with multiple consoles.  And yes,
this is also a thing that people really do use.

logind is essentially a redoing of this entire architecture into something
that's cleaner and handles more of the edge cases properly.  And my
understanding is that it really *is* superior -- if you're working in this
space, it solved real problems for you, and was (and is) getting a level
of active development that's much higher than the alternatives.

> 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.

And they took the opportunity to rethink the space and think hard about
what the APIs and behavior really should be, and they did significant
cleanup on all that stuff in a way that hides more of the complexity from
the other projects.  (Which IMO is a two-word description of the key to
good software design: hide complexity.)  Now, not everyone agrees with
exactly how they cleaned up this space -- not by any stretch.  But it is a
coherent and maintained API model, and a fair bit of thought has gone into
it, with lessons learned from previous attempts.

> 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.

Pretty sure there's no dependency on journald.  I think you have to use
systemd's syslog passthrough if you're launching systems under systemd as
an init system (although I'm not 100% sure about that even), but that's
not the same thing as journald or the journal itself, and that's systemd
as an init system, not logind, which can run separately.

> 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.

Lock-in is such a weird way of describing free software and published
interfaces.  It's not at all the way that we were using that term back in
the days of Microsoft trying to kill free software.

Maybe it's just that I've been around for a long time now, but I am
completely mystified by this supposed lock-in concept.  It makes no sense
to me whatsoever, even after lots of people trying to explain it at great
length.

It's *way* easier to replace systemd components than it was to replace
/bin/login across seven versions of proprietary UNIX, and I and others did
that all the time.  It meant having to redo everything /bin/login did,
which was a giant pain in the ass, so it was miserable to have to do it,
but we needed to do it to get where we wanted to go, so we did.  systemd
is no different -- it's just software.  It's *free* software, in fact, so
unlike with /bin/login where we had to reverse-engineer code for which we
had no source, all you have to do is grab whatever bits of systemd you
still need, tack them on to whatever you're doing, and as long as you're
okay with using the GPL, you're all set.  You can even do that on an
ongoing basis.

You're about as locked in to systemd as you are into readline.  If people
write a widely-useful piece of software, surprise surprise lots of other
software starts using it.  That software will be written to that API.
That means that, if you want to replace it, you will have to reimplement
that API or convince a lot of software to change what it relies on.  But
that's just *normal*.  That's how free software has always worked.  That's
not lock-in -- or, put another way, if that's lock-in, 90% of the software
in our archive is locked into one thing or another.

The alternative would be vast amounts of basically wasted effort writing
two implementations of absolutely everything, not because you actually
have problems you're trying to solve, or any unique approach to the
problem, but just so that you can say that you have two implementations.
If that sort of thing turns your crank, by all means, knock yourself
out -- I'm happy to see people pursue anything they like to work on in the
free software world.  But that certainly doesn't sound fun, interesting,
or particularly useful to the broader world to me.

I'm quite happy to have just one implementation of something as long as I
can fork it when I need to change it.  systemd is under the GPL, so I have
all the free software freedoms, so I'm happy -- if anything seriously bugs
me about it, I'll fork it with other like-minded people.  If there aren't
enough other like-minded people, that's *my* oproblem, not systemd's, in
exactly the same way that the FSF Emacs maintainers have no obligation to
keep XEmacs development alive just so that we have two good
implementations of Emacs.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>