Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
en:philosophy:systemd_denial [2022/11/03 17:52]
throgh
en:philosophy:systemd_denial [2022/11/18 12:37] (current)
throgh [Points for criticism in detail]
Line 9: Line 9:
 As Hyperbola is created as pure lightweight system the orientation of systemd is not following the [[:social_contract|Social Contract]] to **respect modular and lightweight design**. This was announced within 2017 in a dedicated [[https://www.hyperbola.info/news/end-of-systemd-support/|news-entry]]. As Hyperbola is created as pure lightweight system the orientation of systemd is not following the [[:social_contract|Social Contract]] to **respect modular and lightweight design**. This was announced within 2017 in a dedicated [[https://www.hyperbola.info/news/end-of-systemd-support/|news-entry]].
  
-With the essential design-decision being just more than only init and management systemd has also included more attack surfaces and further security-issues. To be mentioned there are dereferencing null pointers ([[https://github.com/systemd/systemd/pull/5998|Issue 5998]]), or writing out of bounds, or not supporting fully qualified domain names, or giving root privileges to any user whose name begins with a number ([[https://github.com/systemd/systemd/issues/6237|Issue 6237]]). Yes, all of them solved or handled in other ways. But a big monolithic codebase of a project like systemd is staying also complete intransparent for everyone with not a big amount of time and the reaction of maintainers behind the project are also not that kind of helpful: Communication is a basic element for a good project oriented onto **technical emancipation** as this is the absolute basic for free culture and free, libre software on its own.+With the essential design-decision being just more than only init and management systemd has also included more attack surfaces and further security-issues. To be mentioned there are dereferencing null pointers ([[https://github.com/systemd/systemd/pull/5998|Issue 5998]]), or writing out of bounds, or not supporting fully qualified domain names, or giving root privileges to any user whose name begins with a number ([[https://github.com/systemd/systemd/issues/6237|Issue 6237]]). Yes, all of them solved or handled in other ways. But a big codebase of a project like systemd is staying also complete intransparent for everyone with not a big amount of time and the reaction of maintainers behind the project are also not that kind of helpful: Communication is a basic element for a good project oriented onto **technical emancipation** as this is the absolute basic for free culture and free, libre software on its own.
  
 ===== Back and forth: The role of init-systems ===== ===== Back and forth: The role of init-systems =====
Line 21: Line 21:
 We will never address criticism making usage of personal attacks as we conclude neither being unfair nor using false argumentation methods. Besides there are many points to be found making it further a problem to use systemd for any system with lightweight focus. We will never address criticism making usage of personal attacks as we conclude neither being unfair nor using false argumentation methods. Besides there are many points to be found making it further a problem to use systemd for any system with lightweight focus.
  
-=== Breaking promises and immaturity ===+=== Breaking promises ===
  
 “After udev is merged into the systemd tree you can still build it for usage outside of systemd systems, and we will support these builds officially. In fact, we will be supporting this for a long time” “After udev is merged into the systemd tree you can still build it for usage outside of systemd systems, and we will support these builds officially. In fact, we will be supporting this for a long time”
Line 32: Line 32:
 http://lists.freedesktop.org/archives/systemd-devel/2015-June/033170.html http://lists.freedesktop.org/archives/systemd-devel/2015-June/033170.html
  
-=== Stability Promises ===+=== Stability failed ===
  
 "Starting with version 26 (the first version released with Fedora 15) we promise to keep a number of them stable and compatible for the future." "Starting with version 26 (the first version released with Fedora 15) we promise to keep a number of them stable and compatible for the future."
Line 39: Line 39:
 <note>This stability promise was broken as one of their [[http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/|promises]] is for the [[http://www.freedesktop.org/wiki/Software/systemd/export/|export format]]: This is not true for version 44 of systemd for example!</note> <note>This stability promise was broken as one of their [[http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/|promises]] is for the [[http://www.freedesktop.org/wiki/Software/systemd/export/|export format]]: This is not true for version 44 of systemd for example!</note>
  
-=== Scope creep ===+=== Scope of the project ===
  
 [[http://article.gmane.org/gmane.linux.hotplug.devel/17392|systemd includes udev]] [[http://article.gmane.org/gmane.linux.hotplug.devel/17392|systemd includes udev]]
Line 59: Line 59:
 [[http://www.phoronix.com/scan.php?page=news_item&px=Systemd-Mount|systemd includes mount]] [[http://www.phoronix.com/scan.php?page=news_item&px=Systemd-Mount|systemd includes mount]]
  
-=== Absurd Bugs and Responses ===+=== Problematic bugs and responses === 
 + 
 +[[https://bugs.freedesktop.org/show_bug.cgi?id=74589|Unchecked null pointer dereferencing in PID 1 not considered a serious issue]]] 
 + 
 +[[http://www.phoronix.com/scan.php?page=news_item&px=MTYwMzg|Screen locking issues (including a security issue) with gnome-shell remains unfixed]] 
 + 
 +[[http://soylentnews.org/article.pl?sid=14/12/21/1343258|PID 1 segfaulting on upgrade; journalctl usability issue]] 
 + 
 +[[https://lists.debian.org/debian-user/2015/02/msg00010.html|Fail boot for the computer as systemd demands strict sequences]] 
 + 
 +[[https://bugzilla.opensuse.org/show_bug.cgi?id=918226|systemd segfaults after updating from 208-23.3 to 208-28.1]] 
 + 
 +[[https://github.com/systemd/systemd/issues/2402|Mount efivarfs read-only]] 
 + 
 +[[https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776171|Unable to shutdown]] 
 + 
 +[[https://bugs.freedesktop.org/show_bug.cgi?id=61191|journald eats up CPU]] 
 + 
 +[[https://bugs.freedesktop.org/show_bug.cgi?id=64116|Corrupted binary logs]] 
 + 
 +[[https://www.agwa.name/blog/post/how_to_crash_systemd_in_one_tweet|How to Crash Systemd in One Tweet]] 
 + 
 +[[http://www.openwall.com/lists/oss-security/2017/01/24/4|systemd v228 local root exploit]] 
 + 
 +[[https://github.com/systemd/systemd/issues/5644|tmpfiles: R! /dir/.* destroys root]] 
 + 
 +[[https://github.com/systemd/systemd/issues/6237|systemd can't handle the process privilege that belongs to user name startswith number, answered as being "not a bug"]] 
 + 
 +[[https://serverfault.com/questions/755818/systemd-using-4gb-ram-after-18-days-of-uptime|systemd using 4GB RAM after 18 days of uptime]]
  
 === Conceptional problems === === Conceptional problems ===
  
-=== Scope Creep Leads to Vulnerabilities ===+[[http://soylentnews.org/article.pl?sid=14/12/21/0145243|systemd Prevents the Skipping of fsck while Booting]]] 
 + 
 +[[http://soylentnews.org/article.pl?sid=14/12/21/1554227|Default to using Google nameservers]] 
 + 
 +[[https://github.com/systemd/systemd/issues/437|timeX.google.com provide non standard time]] 
 + 
 +[[https://bugs.freedesktop.org/show_bug.cgi?id=76935|Do not parse "debug" command line parameter]]
  
-=== Poor design ===+[[https://github.com/systemd/systemd/issues/2447|Journal ip anonymization]]
  
-=== Ignorance of fundamental operating system concepts ===+[[https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394|systemd kills background processes after user logs out]]
  
 +===== Conclusion for the Hyperbola-project =====
  
 +With the retrospective of all the points listed here Hyperbola has the stance not to accept systemd. It is just the point that there are better alternatives fitting within the approach of a lightweight and stable context for a modern operating-system based on the essentials of the Unix philosophy. It is not a denial as we for sure just see no usecase for a so complex and also bloated piece of software to be used. Our ideal in this: **We search for alternative ways as it is an an achievement of civilization that not all need to be the same but treated nevertheless with fairness and therefore in conclusion the same way!**
  
-== Absurd Bugs and Responses == +So systemd has to persist the comparison towards other possible init-systems and in that way is for sure too bigtoo complex and full with flaws we don'want to accept as we would therefore need to be worried even on top of continuous upgrades for just one essential partAnd even though every single point can be declared as solved or in some way olderwe just don'want to use systemd as single-point for failure as it just this simple.
-* [https://bugs.freedesktop.org/show_bug.cgi?id=74589 Unchecked null pointer dereferencing in PID 1 not considered a serious issue] - <i>"To make this work we'd need a patch, as nobody of us tests this."</i>, <i>"I will not work on this"</i> - Systemd <b>requires</b> cgroups and segfaults if there is no cgroups support. +
-* [http://www.phoronix.com/scan.php?page=news_item&px=MTYwMzg Screen locking issues (including a security issue) with gnome-shell] - remained unfixed for over a year] +
-* [http://soylentnews.org/article.pl?sid=14/12/21/1343258 PID 1 segfaulting on upgrade; journalctl usability issue] - bug report still marked as "NEW" +
-* [https://lists.debian.org/debian-user/2015/02/msg00010.html "Tried to boot my laptop from a cafe..."+
-* [https://bugzilla.opensuse.org/show_bug.cgi?id=918226 systemd segfaults after updating from 208-23.3 to 208-28.1] +
-* [https://github.com/systemd/systemd/issues/2402 Mount efivarfs read-only] - Doing rm -rf / bricks your computer +
-* [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776171 Unable to shutdown] +
-* [https://bugs.freedesktop.org/show_bug.cgi?id=61191 journald eats up CPU] +
-* [https://bugs.freedesktop.org/show_bug.cgi?id=64116 Corrupted binary logs] +
-* [https://www.agwa.name/blog/post/how_to_crash_systemd_in_one_tweet How to Crash Systemd in One Tweet] (works as any user, not just root) and [https://medium.com/@davidtstrauss/how-to-throw-a-tantrum-in-one-blog-post-c2ccaa58661d response] and [https://www.agwa.name/blog/post/systemd_is_not_magic_security_dust rebuttal] +
-* [http://www.openwall.com/lists/oss-security/2017/01/24/4 Systemd v228 local root exploit] +
-* [https://github.com/systemd/systemd/issues/5644 tmpfiles: R! /dir/.* destroys root] See also [https://www.preining.info/blog/2017/04/systemd-again/ Systemd again (or how to obliterate your system)], Poettering's response: <i>"I am not sure I'd consider this much of a problem. Yeah, it's a UNIX pitfall, but "rm -rf /foo/.*" will work the exact same way, no?"</i> (Hint: no.) +
-* [https://github.com/systemd/systemd/issues/6237 systemd can't handle the process previlege that belongs to user name startswith number, such as 0day] Poettering: "not a bug, a feature" +
-* [https://serverfault.com/questions/755818/systemd-using-4gb-ram-after-18-days-of-uptime systemd Using 4GB RAM After 18 Days of Uptime] +
-== Conceptional problems == +
-* [http://soylentnews.org/article.pl?sid=14/12/21/0145243 Systemd Prevents the Skipping of fsck while Booting] - still unresolved +
-* [http://soylentnews.org/article.pl?sid=14/12/21/1554227 Systemd Disables the Linux Magic SysRq Key] - closed as "NOTABUG" +
-* [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761658 Please do not default to using Google nameservers] - Debian package maintainer refuses to acknowledge the privacy leak and closed the bug. +
-* [https://github.com/systemd/systemd/issues/437 timeX.google.com provide non standard time] - Horrible default behaviour but Lennart tries to shift the blame on distros because "systemd is not a product"+
-* [https://bugs.freedesktop.org/show_bug.cgi?id=76935 Do not parse "debug" command line parameter] - [https://lkml.org/lkml/2014/4/2/415 Response on LKML] Response: [https://bugs.freedesktop.org/show_bug.cgi?id=76935#c2 That is the expected current behaviour, "debug" can cause "too many" messages to be useful anymore if things are broken.] +
-* [https://github.com/systemd/systemd/issues/2447 journal ip anonymization] - It's very difficult to use systemd/journal on a privacy aware system or infrastructure. +
-* [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394 systemd kill background processes after user logs out] - Poettering's answer: [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/XW7V5A3RAWYCACU2ZMPA27ARRLIZUI37/ In my view it was actually quite strange of UNIX that it by default let arbitrary user code stay around unrestricted after logout.] +
-* [http://edgeofsanity.net/rant/2017/12/20/systemd-resolved-is-broken.html systemd-resolved is broken] - doing DNS resolve wrong, with the [https://github.com/systemd/systemd/issues/5755 usual attitude towards feedback] +
-Debunking the myth of unit files being significantly shorter than scripts used by all other init systems: [https://jdebp.eu/FGA/run-scripts-and-service-units-side-by-side.html A side-by-side look at run scripts and service units] +
-== Scope Creep Leads to Vulnerabilities == +
-* [http://seclists.org/oss-sec/2014/q4/592 systemd-resolved DNS cache poisoning] +
-* To run systemd properly in container a FUSE [https://linuxcontainers.org/lxcfs/introduction/ LXCFS] had to be created, and surely its own share of vulnerabilities: +
-** [https://www.cvedetails.com/cve/CVE-2015-1342/ LXCFS before 0.12 does not properly enforce directory escapes] CVSS 4.6 +
-** [https://www.cvedetails.com/cve/CVE-2015-1344/ The do_write_pids function in lxcfs.c in LXCFS before 0.12 does not properly check permissions] CVSS 7.2 +
-* [https://latesthackingnews.com/2017/06/29/a-systemd-vulnerability-allows-attackers-hack-linux-machines-via-malicious-dns-response/ A Systemd Vulnerability Allows Attackers Hack Linux Machines via Malicious DNS response] +
-== Poor design == +
-* [https://bugs.freedesktop.org/show_bug.cgi?id=76935#c10 Improper argument parsing] +
-* [http://www.freedesktop.org/software/systemd/man/systemd.special.html 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'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 [https://en.wikipedia.org/wiki/Slice_(disk) disk partition] yet their usage is completely unrelated. +
-* [https://news.ycombinator.com/item?id=10999335 Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'] See also [https://bbs.archlinux.org/viewtopic.php?id=207549 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 [https://en.wikipedia.org/wiki/Principle_of_least_privilege principle of least privilege].  Lennart goes on to state that [https://github.com/systemd/systemd/issues/2402#issuecomment-177907110 systemd needs to write EFI variables].  This demonstrates yet another example of scope creep and thus poor design. +
-* http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=ubuntu&id=28640752854 +
-* https://bugzilla.redhat.com/show_bug.cgi?id=1170765 +
-* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784720 +
-* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394 "Now you can no longer expect a long running background processes to continue after logging out. For example, you can no longer start a screen or tmux sessionlog out, and expect to come back to it." +
-* https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ systemd's predictable NIC names are actually unpredictable... +
-== Ignorance of fundamental operating system concepts == +
-* [http://lists.freedesktop.org/archives/systemd-devel/2015-February/028514.html Lead systemd developer doesn'understand RAID or checksum] +
-* [https://github.com/systemd/systemd/issues/825#issuecomment-127917622 Lead systemd developer doesn't understand ''su'', expects it to do something else and then labels it "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 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.+