Arguments against systemd
From Without Systemd
Contents |
Please objectively explain issues and link a reliable source (commit, bug report or documentation).
Scope creep
systemd suffers from scope creep.
- systemd is an init system
- systemd provides an UEFI boot loader, systemd-boot (previously gummiboot)[1]
- systemd provides a login manager, systemd-logind
- systemd provides a syslog daemon, systemd-journald, see Introducing the Journal
- uses a binary format
- systemd provides a mount front-end, systemd-mount[2]
- The udev sources were merged into the systemd source tree.[3]
- systemd provides systemd.timer timer units, which can be used to replace cron and at
- systemd provides a D-Bus client library, sd-bus (see sd-bus)
- systemd developed an in-kernel D-Bus implementation, kdbus.[4] They tried to get it merged into the kernel, failed, and are now trying again with BUS1.[5]
- systemd provides automount via systemd.automount to substitute autofs
- systemd provides a caching DNS resolver, systemd-resolved
- systemd provides a network manager and DHCP client, systemd-networkd
- systemd provides a HTTP server for journal events, systemd-journal-gatewayd (can be disabled with
remotecompile option) - systemd provides a containerization system systemd-nspawn (see lwn - Systemd vs. Docker)
See Wikipedia:File:Systemd components.svg.
To be added: systemd-cryptsetup, pam_systemd, acpi, cgroups, gnome-session, tcpwrapper, audit
- systemd Gains IP Forwarding, IP Masquerading & Basic Firewall Controls
- https://lists.dns-oarc.net/pipermail/dns-operations/2016-June/014933.html
-
An init system that requires even on a server a library for rendering QR codes: Post in Heise Forum and reference in Fedora
Issues
- fsck cannot be cancelled (used to be possible via C-c or c on the console). 7f110ff9b8, Fedora#719952
- systemd defaults to Google's DNS nameservers. e16cb2e4ef, Debian#761658
- systemd defaults to Google's NTP servers, which serve leap-smeared time. GitHub#437
- systemd by default uses Predictable Network Interface Names, which are actually less predictable when you only have one interface per type.
- systemd by default kills background processes after the user logs out. 97e5530cf2, Debian#825394
"In my view it was actually quite strange of UNIX that it by default let arbitrary user code stay around unrestricted after logout." -Poettering[6] - As systemd depends on many files on a rootfs, in case of any problems with rootfs, it is not able to control processes and (cleanly) shutdown/reboot when Crtl-Alt-Del is pressed.[7]
- systemd-resolved breaks the traditional glibc behavior by skipping a DNS server in all following queries, if it does not respond once. GitHub#5755, [8]
Conceptional problems
- Do not parse "debug" command line parameter - Response on LKML Response: That is the expected current behaviour, "debug" can cause "too many" messages to be useful anymore if things are broken.
- journal ip anonymization -- It's very difficult to use systemd/journal on a privacy-aware system or infrastructure.
Poor design
- systemd has a filename that starts with a hyphen! - This causes all sorts problems as it will usually be interpreted as the start of a command option when used on the command line. You don't even need to specify the filename for it to cause problems as it will affect commands that use globbing. Not to mention that the file in question, "-.slice", they refer to as the "root slice" which causes confusion as the term "slice" has been used for decades as an alternative way of referring to a disk partition yet their usage is completely unrelated.
- systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm' See also No POST after rm -rf / - Lennart's argument for mounting /sys/firmware/efi/efivars as read/write as a default behaviour doesn't hold water. Yes it's true that some tools may need to write to it but those tools are not needed for the general running of a system. efivars should not even be mounted as read-only by default. Those tools that need to write to efivars will generally only be invoked by a system administrator. A competent sysadmin will know how to mount efivars with read/write permissions when they need to to use those tools. The only reason to mount efivars by default is for convenience. This is by no means a good reason. From a security perspective, mounting efivars by default should be strongly discouraged as it breaks the principle of least privilege. Lennart goes on to state that systemd needs to write EFI variables. This demonstrates yet another example of scope creep and thus poor design.
- https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=28640752854
- https://bugzilla.redhat.com/show_bug.cgi?id=1170765
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784720
- systemd units are started with zero context. This eliminates most of the functionality of inotify and makes systemd.path unusable for virtually any purpose.
Scope creep leads to vulnerabilities
- systemd-resolved DNS cache poisoning
- To run systemd properly in container a FUSE LXCFS had to be created, and surely its own share of vulnerabilities:
- systemd vulnerability allows attackers to hack Linux machines via malicious DNS response
- Remote code execution via DHCPv6
- System Down: several vulnerabilities in systemd-journald The Register article on same
CVEs
- CVE-2019-6454 systemd (PID1) crash with specially crafted D-Bus message USN-3891-1
- CVE-2018-16866 information leak, out-of-bounds read
- CVE-2018-16865 memory corruption
- CVE-2018-16864 memory corruption
- CVE-2018-15688 buffer overflow in the dhcp6 client
- CVE-2018-15687 set arbitrary permissions on arbitrary files
- CVE-2018-15686 potential root privilege escalation
- CVE-2018-6954 obtain ownership of arbitrary files
- CVE-2018-1049
- CVE-2017-1000082 parsing error leads to root privilege escalation
- CVE-2017-9217
Absurd bugs and responses
- Debian#739593 systemd makes / shared by default, poettering suggest to not patch this, because you'll broke a lot of containers
- freedesktop#74589 Unchecked null pointer dereferencing in PID 1 not considered a serious issue.
- openSUSE#918226 systemd segfaults after updating from 208-23.3 to 208-28.1
- GitHub#2402 Mount efivarfs read-only - Doing rm -rf / bricks your computer
- Debian#776171 Unable to shutdown
- freedesktop#61191 systemd-journald eats 100% CPU
- freedesktop#64116 Corrupted binary logs
- GitHub#5644 tmpfiles: R! /dir/.* destroys root, also see systemd again (or how to obliterate your system)
- GitHub#6237 systemd can't handle the process previlege that belongs to user name startswith number, such as 0day
- GitHub#2039 Default value of RemoveIPC doensn't allow to use third party daemons. -- "This is an issue tracker, not a support forum."
- GitHub#8596 redhat#1494014 systemd incorrectly unmounts a reused mount point after a device removal / systemd automatically unmounts filesystem mounted using "mount <mountpoint>" command
- Github#9602 systemd won't allow the system to start if the system is configured correctly (/etc/localtime as a symlink) (you can even use systemd's tool to configure it!)
Missing bug report link:
- how to crash systemd in one sweet (works as any user, not just root) and response and rebuttal
- systemd v228 local root exploit
- systemd Using 4GB RAM After 18 Days of Uptime
- Phoronix - Screen locking issues (including a security issue) with gnome-shell -- remained unfixed for over a year
- SoylentNews - PID 1 segfaulting on upgrade; journalctl usability issue - bug report still marked as "NEW"
- "Tried to boot my laptop from a cafe..."
Unprofessionalism
Linux (kernel) coup attempt:
- "kdbus support is no longer compile-time optional ... We encourage all downstream distributions to begin testing kdbus by adding it to the kernel images in the development distributions, and leaving kdbus support in systemd enabled."[9]
"kdbus dropped in favor of BUS1"
- systemd promised that their Journal File Format is stable starting with version 26.[10] Version 44 however does not follow, "Entry metadata that is not actually a field is serialized like it was a field, but beginning with two underscores."
Ignorance of fundamental operating system concepts
- Lead systemd developer doesn't understand RAID or checksum
- Lead systemd developer doesn't understand su, expects it to do something else and then labels it a "broken concept" - su isn't supposed to inherit cgroups or audit, those concepts are relatively new and arrived well after the creation of su. TTYs were originally physical devices so of course su is supposed "inherit" the same device otherwise it would be truly broken. Pseudo TTYs emulate real TTYs so their behaviour is obviously expected to be identical. su really is just a simple mechanism that calls setuid(2) in order to switch to another user. If he needs to write a new utility to handle scenarios that su was never designed to handle, no problem, but to label it as a "broken concept" demonstrates a lack of understanding of what su actually is.
