[systemd-devel] feature request: dlopen

[Tobias Hunger]

Hi Luke,

On Mon, Feb 23, 2015 at 3:08 AM, Luke Kenneth Casson Leighton
<lkcl at lkcl.net> wrote:
>  the problem, zbigniew, is that the intended use of this "silent noop"
> feature - to make it *possible* to have an alternative PID1 - *hasn't
> happened*.  any upstream software developer who has added in support
> for systemd has done so by *ripping out* the former alternative code.
> not a single upstream system that i've seen has done *any* kind of
> run-time detection *at all*.  it's all compile-time.

You are starting to mix things: Libsystemd does work the way it was
intended: They make it possible to add socket activation to daemons
and make those report back to systemd. That part is nicely
encapsulated.

There are unrelated things like systemd-logind, which are higher up in
the stack. Those are indeed harder to replace. Part of the problem is
that there are no fully functionally equivalent pieces of software to
replace the systemd stuff with. ConsoleKit and Co. do have severe
limitations, that (apparently) can not be fixed without resorting to
cgroups.

>  aside from getting the message across to upstream developers about
> doing runtime detection, i feel that what you guys really need to do
> is to set up conferences with everyone, to talk - urgently - about
> ways to ensure that the alternative systems which the wholesale
> adoption of systemd has excluded may be reinstated as *runtime*
> choices (not compile-time).  that may mean discussing a set of APIs
> that end up being DL'd (like PAM is, right now), it may mean doing
> something similar to apache loadable modules, or something like the
> infrastructure behind python objects, i don't know, but you *need to
> talk*.

I do expect developers to search for information and not wait for "the
systemd project" (whoever that is) to feed it to them.

E.g. I would expect people that want to do a distribution without
systemd will actually find out what systemd does first, so that they
can do informed decisions on how to replace the individual parts. The
documentation of systemd is -- at least in my experience -- pretty
good in most areas. And where it is lacking people tend to act when
somebody pokes them about it and actually improve on it.

What do you want to be able to reinstate as runtime choices? There is
a lot of stuff in the systemd repository. Those parts are at different
levels of the stack and with varying levels of dependency on other
parts.

Your request is so generic that it is impossible to answer.

> the situation now is one where people believe that systemd is being
> heavily promoted to the exclusion of all other PID1 alternatives,
> developed with a focus on fedora / redhat to the exclusion of all
> other distros, developed for desktop systems *only* to the exclusion
> of servers and embedded systems... it's no wonder that there's a lot
> of upset people in the software libre community!

That is a complete mis-representation of the project. Unfortunately I
doubt there is anything the systemd project can do to rectify that
impression at this point: Many people are past rational arguments at
this point.

>  i know it sounds weird to go backwards, but the situation is -
> amongst other not very nice things - that the GNU/Linux world now has
> a new monoculture attack vector at the PID1 level.... in code that's
> being *actively developed and extended, dramatically*.

I do not understand this point. Systemd PID1 is pretty small, the rest
of systemd runs with severely limited privileges. In fact most
services are more tied down than their traditional counterparts ever
were.

>  it was bad enough that shellshock meant that sysvinit was vulnerable
> right across the board of every GNU/Linux distribution.  but at least
> sysvinit is old enough to have had significant security audit and
> review over the decades, such that when shellshock was fixed, that was
> it, problem solved [until the next vulnerability...]

Shellshock was lurking in the code for decades, evading all the
security audits and reviews done on bash in all that time. Xorg has
had similar long-lived bugs.

Sysv-rc also depends on a lot of external code. The shell, core
utilities, awk and whatnot. I doubt all the whole mess ever was
audited for security in its total.

>  contrast that to the situation now: with systemd being so actively
> developed and then deployed across literally every major GNU/Linux
> distro without exception, the possibility for serious vulnerabilities
> having a disproportionately large adverse effect is much higher than i
> feel it should be.

The same is true for the Linux kernel, and I am more than happy about
that. Bugs do get found in actively developed code, simply because
people actually look at that code!

Maybe we should all run more BSDs? That would also reduce the reliance
on systemd:-) Two birds with one stone.

Best Regards,
Tobias