Hacker News new | past | comments | ask | show | jobs | submit login

The security track record of those existing systems you refer to: - bind - isc DHCP - dnsmasq - ntpd - radvd - rsyslog - syslog-ng

The name enumeration alone should ring bells.

There's always more that can be done, but https://github.com/systemd/systemd/tree/master/src/fuzz contains more than most of the aforementioned combined.

As for how your run your alternative services as non root, you may wish learn about what the contents of this file means: https://github.com/systemd/systemd/blob/master/units/systemd... or this one: https://github.com/systemd/systemd/blob/master/units/systemd...

Can you point to a commonly used initrc that comes even remotely close?

You should also read https://systemd.io/JOURNAL_FILE_FORMAT/ and NetworkManager, which is what Ubuntu uses.

By all means bash away (pun intended), but I keep seeing these points go uncontested and they're not very well founded.




I claim init systems shouldn't open network connections.

Sure, bind has a terrible security record, and that was part of the reason why people started writing more secure replacements like unbound.

NTP has a terrible security record, and that's part of the reason people started writing more small secure replacements like NTPsec and chrony.

Similarly sendmail's security issues resulted in improvements like postfix, which hasn't been swallowed into system yet, mostly kidding.

Linux often has multiple implementations for a given service and ease of use, performance, security and related allows them to compete. This is a sign of a healthy ecosystem and generally I think it's working well.

However systemd, by rolling this functionality into systemd subverts that system and the vast majority of systems will just accept the defaults. It also makes systemd huge and complex, last I looked there was somewhere around 5% of the lines of code in systemd than the entire linux kernel which I find scary.


systemd the init system does not open network connections. systemd PID1 does not talk to the network. `networkd` is a separate binary.

Second, systemd does not mandate using any of these components apart from `journald` and `logind`. You can pipe journald into any syslog daemon of your choice, there's a config option to do so. If you've got issues with logind I can't help you there. I don't know what it was intended to replace (consolekit, I think?) but I do remember it was badly maintained.

Third, a vast majority of deployments do _not_ accept defaults. I know that both Red Hat and Debian go for third party network managers (networkmanager and Debian's ifup/ifdown stuff) and rsyslogd was there on a default install of both Debian Buster and CentOS 8 iirc.

Finally, I repeat, systemd is a monorepo which contains many programs. Sure, you can argue about how they're tightly bound, but I can point you towards FreeBSD/OpenBSD if you'd want them to be broken up into separate repos to be more "unix-y", and if you look at systemd PID1 it's a fairly small binary which doesn't seem to offer many security holes.


Finally the biggest mistakes systemd project did is on the marketing and strategy sides.

Would have they remove the "systemd-" prefix from all side binaries and marketted them as independant projects on the website, made them usable without systemd and maybe on sub repositories, would have the systemd project just had to explain "yes we rewrite ntp, dns, etc, why not ?"

Instead they received complains about a "bloat ware" while often rewrites of industry-standard by unknown/junior people are acclaimed on HN :)

Even better, they could have integrated chronyd or others by creating "systemd integration standards" and submitting patches to these projects to gain community support and permit an easy switch to one or another implementation and let the users chose. Though it s still already easy to use something else than timesyncd on centos at least, thanks to systemd project and distri maintainers too :)


You can't have any stable integration standard when systemd's scope is ever increasing, or paper it over with marketing. Even stuff like home directories now Must Be Improved.

It isn't comparable with typical rewriting of industry-standard by newbies.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: