[systemd-devel] feature request: dlopen

[Luke Kenneth Casson Leighton]

On Mon, Feb 23, 2015 at 12:52 AM, Zbigniew Jędrzejewski-Szmek
<zbyszek at in.waw.pl> wrote:
> On Sun, Feb 22, 2015 at 11:58:25PM +0000, Luke Kenneth Casson Leighton wrote:

>>  ...except that its introduction (usually --with-libsystemd) in those
>> 100 (or so) packages has been done in a mutually-exclusive,
>> hard-compile-time switch that *excludes* the possibility of dynamic
>> (runtime) decision-making.

> I think this is the crux of the matter. Please accept the fact that
> this compile time switch does not preclude runtime decision making at
> all. When not running under systemd, calls into libsystemd degrade
> into silent noops. So they only "cost" that is an extra unused 600kb
> library, which is completely insignificant.

 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.

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

 and you know what?  if you were to say, "we're genuinely concerned
that the alternatives to systemd are being locked out, let's talk,
urgently. we really mean it", i think you'd find that people would
respond positively.

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!


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

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

 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.

l.