Bug#727708: systemd (security) bugs
Don Armstrong <don@debian.org> writes:
> Projects which have multiple components, each of which has different
> security/interface surfaces without stable defined interfaces, can lead
> to problems when one set of developers doesn't understand the security
> implications of the parts that they do not work on.
It's unclear to me that this is a correct characterization of systemd. Do
the separate components of systemd not have stable, defined interfaces? I
know they largely don't have other implementations, but that's not the
same thing.
> The combination of components into a single monolith is sometimes
> necessary, but it's not clear that it is so in the case of systemd.
systemd is a large package from a source code perspective, but it's not my
impression that the result of building that source is a monolith. Rather,
it's a variety of separate, interoperating services, which strikes me as a
good general model. In fact, that design is what makes it possible to
consider using upstart and still support GNOME, since it means that logind
is separable from systemd with some effort. That strongly implies that
systemd is not a monolith.
I think the concern on the systemd side is not stemming from unstable
interfaces but from *evolving* interfaces, which is not the same thing.
In other words, the current systemd services do not implement all the
functionality that will be eventually needed, particularly by desktops, so
those interfaces will grow with time, and may require further D-Bus, udev,
cgroups, and similar integrations.
Let me put it this way. I think there are a couple of givens here, some
of which have been expressed by both the GNOME maintainers and the KDE
maintainers and which are also reflected by the current state of Ubuntu:
* We use udev as the default device management platform and will continue
to do so regardless of the init system we choose.
* Many of the other systemd services, particularly logind but also several
of the others, are quite desirable or even necessary for desktop
environments, so we will need to adopt those services in Debian
regardless of what init system we choose. Obviously, if we adopt
systemd, integrating those services into the distribution is quite
straightforward. If we don't adopt systemd, there are some critical
missing integrations (relative to the normal systemd infrastructure)
that will have to be replaced. The cgroups manager appears to be the
most significant one at the moment.
If the interfaces for those supplemental components are actually unstable,
that's going to pose problems all around, but I'm not sure how directly
relevant to this discussion that is since we're going to have to deal
with those components *anyway*. Choosing a different init system than
systemd is not going to let us ignore logind, since it's going to be a
required component for a modern desktop. (Although it would still be good
to know if this is the case.)
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: