systemd: unit files, sd_notify support; OpenRC init scripts

[Kangie]

Add OpenRC and systemd init files for cross-distribution compatibility. Also includes a rebased and updated sd_notify support patch from #251, in line with usage by Red Hat/Fedora, OpenSuSE, and Debian. Feedback welcome.

[rossburton]

The unit files and patch are in use by multiple major distributions. Is there anything blocking this being merged?

[fogti]

In light of recent developments (https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27), it appears that it would be a better idea to inline sd_notify instead and not link to systemd at all. (of course, this isn't my idea)

[Kangie]

The unit files and patch are in use by multiple major distributions. Is there anything blocking this being merged?

Willingness from the maintainers here, I guess?

[djmdjm]

Willingness from the maintainers here, I guess?

License incompatibility and library bloatedness were the reasons. Given recent events we're never going to take a dependency on libsystemd, though we might implement the notification protocol ourselves if it isn't too much work.

[Kangie]

In light of recent developments (https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27), it appears that it would be a better idea to inline sd_notify instead and not link to systemd at all. (of course, this isn't my idea)

To quoth poettering (https://news.ycombinator.com/item?id=39867126)

Uh. systemd documents the protocol at various places and the protocol is trivial: a single text datagram sent to am AF_UNIX socket whose path you get via the NOTIFY_SOCKET. That's trivial to implement for any one with some basic unix programming knowledge. And i tell pretty much anyone who wants to listen that they should just implement the proto on their own if thats rhe only reason for a libsystemd dep otherwise. In particular non-C environments really should do their own native impl and not botjer wrapping libsystemd just for this.
But let me stress two other things:

Libselinux pulls in liblzma too and gets linked into tons more programs than libsystemd. And will end up in sshd too (at the very least via libpam/pam_selinux). And most of the really big distros tend do support selinux at least to some level. Hence systemd or not, sshd remains vulnerable by this specific attack.

For this:

Given recent events we're never going to take a dependency on libsystemd, though we might implement the notification protocol ourselves if it isn't too much work.

The above makes it seem straightforward and that is probably the correct approach here.

It is courteous to respond to a PR so that it can be improved or dropped. If I was to drop the sd_notify patch would you merge the service definitions?

[eli-schwartz]

License incompatibility and library bloatedness were the reasons. Given recent events we're never going to take a dependency on libsystemd, though we might implement the notification protocol ourselves if it isn't too much work.

It's a big pity you didn't say that a year ago. If you had, the PR could have been reworked to implement the notification protocol internally, and then systems today would not have been vulnerable.

Disappointing that lack of interest in collaboration had this unfortunate downside.

[orazioedoardo]

then systems today would not have been vulnerable

IMHO the backdoor author(s) would have just targeted some other process/binary or targeted SSHD anyway via other mechanism as Poettering explained.

[ghost]

then systems today would not have been vulnerable

IMHO the backdoor author(s) would have just targeted some other process/binary or targeted SSHD anyway via other mechanism as Poettering explained.

"Other people are vulnerable so our vulnerability doesn't matter" 🤦‍♂️

[trip54654]

This is an example of how bloat and feature creep broadens the attack surface. Why should a daemon even link to a service manager specific library?

[kuraga]

The 2e27b20 part?

[quaresmajose]

A standalone implementation that does not depend on libsystemd was merged on 08f5792

[fogti]

It has been brought to my attention that this breaks on non-glibc systems: https://github.com/void-linux/void-packages/blob/7363f7aa5bb16315672103af2a2227c9ff33bd2b/srcpkgs/openssh/patches/musl-connect.patch

[thesamesam]

It's not really much to do with this PR, but that's https://bugzilla.mindrot.org/show_bug.cgi?id=3707 and fixed in master already.