1. SUSE gehört schon lange nicht mehr zu Novell. Nach der Übernahme Novells durch die Attachmate Group (2011) wurden Novell und SUSE wieder zu eigenständigen Unternehmen entflechtet. Das blieb auch nach der Übernahme Attachmates von Micro Focus International (2014) so bestehen. Seit Mitte 2018 gehört SUSE dem Investor EQT Partners AB. Quelle
2. Woher stammt die Zahl von 1,2M LoC? Laut OpenHub handelt es sich eher um circa 660k Zeilen Quelltext, davon sind etwa knapp 500k Zeilen Quelltext (davon ~385k C-Code und ~65k XML z.B. für hwdb(7)), der Rest sind Kommentare (~44k Zeilen) und Leerzeilen (~130k). Andere Zahlen finden sich auch hier. Ich verweise auch auf meine eigens durchgeführte Zählung von Ende Mai.
4. Die Anzahl der Zeilen Quelltext im Quellverzeichnis von systemd bewältigen weitaus mehr Aufgaben als init (oder SysV). Da ist bspw. udev enthalten, sowie viele rein optionale Komponenten (systemd-boot, journald, journalctl, networkd, networkctl, resolved, resolvectl, timesyncd, ...). Ja, der Teil für init ist bei systemd fetter als bei SysV zuvor, insbesondere der init-Prozess. Er kann aber auch sehr viel mehr. Die Fähigkeiten mögen zwar nicht immer notwendig oder gewünscht sein, aber das ist der Preis "universeller" Systeme. Zudem hat man die Option der reichhaltigen Alternativen.
5. Was genau sind Ihrer Meinung nach die "Entwurfsgrundsätze von UNIX-Systemen"? Entspricht der Linux-Kernel und das Entwicklungsmodell der BSDs (alle entwickeln ihren eigenen monolithischen Kernel samt Basissystem ohne Ansprüche auf absolute Minimalität, Orthogonalität, Portabilität oder Unabhängigkeit projektspezifischer Features) auch diesen Grundsätzen?
6. Warum sollen sich die anderen auf Ihre Maximen "besinnen"? Mit welchem Recht machen Sie Ihre Forderungen zum Anspruch geltend? Statt zu nörgeln, habe Sie die Möglichkeit, es besser zu machen. Tragen Sie systemd bei und verbessern es, forken Sie es nach Ihrem gusto und beglücken ggf. den Rest der Welt damit, falls es Ihnen recht ist, oder aber finanzieren, unterstützen, entwickeln, nutzen und/oder verbreiten Sie eine Alternative zu systemd. Sie haben die Wahl.
7. zu "Ein Werkzeug für eine Aufgabe und nicht die eierlegenden Wollmilchsau, [...]": Genau die wollen die wichtigsten Kunden Red Hats aber scheinbar haben. Und was nun? Und welche Teile von systemd sollen Ihrer Meinung nach technisch strikter separiert werden? Oder geht es Ihnen eher um das Entwicklungsmodell (Monorepo) oder die politische Komponente?
8. "[...], die keiner außer den Erstellern mehr überblickt.": Sie suggerieren hier implizit etwas, dass Sie nicht belegen können. Es scheinen viele talentierte und gut bezahlte Administratoren zu existieren, die sich mit ihren Werkzeugen auskennen, sonst würden ständig mittlere digitale Infrastrukturkatastrophen entstehen, die sich allein auf systemd zurückführen ließen und von denen der Otto Normalverbraucher etwas mitkriegen würde. Zudem würde niemand diese Administratoren oder die Software-Lizenzen bezahlen wollen. Haben Sie quantitative Belege für Ihre Aussage?
Ergo: Bitte reden Sie Klartext, streuen Sie keine falschen Fakten ein, belegen Sie Ihre Fakten und Argumente, und ziehen Sie bitte logische Schlüsse und Vergleiche bevor Sie voreilig urteilen. Nur das kann als solide Grundlage für eine erstrebenswert fruchtbare Diskussion gewertet werden. Andernfalls kann man Sie nicht ernst nehmen.
9. Viele Zeilen Quelltext in systemd sind auch mit Absicht geschrieben worden, das Entwickeln und Warten von traditionell unixoiden daemons zu vereinfachen. Daher auch die services aus der Begriffswelt von systemd. Die Verwaltung mehrerer Prozesses eines Dienstes, das traditionelle double-forking, die Abhängigkeiten, die Race-Conditions, das Neustarten, die Init-Skripte, das Isolieren und der dafür in jedem daemon notwendige zusätzliche Code wurden mit systemd angegangen und zu großen Teilen abgedeckt. Vielen Quelltextzeilen systemds stehen also ein Vielfaches an obsoleten Quelltextzeilen in systemd-Diensten gegenüber.
Ja, systemd kann mehr als ein minimales Init. Und genau das ist das Problem in sicherheitsrelevanten use cases.
Zu 5: zumindest OpenBSD befolgt die Grundsätze der Minimalität. Im übrigen sind die Grundsätze von Unix recht gut definiert: https://en.wikipedia.org/wiki/Unix_philosophy
Zu 6: Seit wann ist es eigentlich Mode dass, sobald jemand etwas fordert, unterstellt wird man wolle etwas bestimmen, eine (Meinungs-)Diktatur errichten o.ä. Im Rahmen der Meinungsfreiheit hat jeder das Recht alles mögliche zu fordern.
Mit diesen Unterstellungen und dem ad hominem Angriff am Ende ("man kann Sie nicht ernst nehmen") disqualifiziert sich der Beitrag eigentlich selbst.
zu 2: Die von Ihnen genannte Sekundärquelle ist wie auch der Pro-Linux Artikel, zu welchem ich bereits indirekt mit dem Verweis auf meinen Kommentar mit eigener Zählung verwies, mehr oder minder reißerischer Clickbait. Die Primärquelle ist Phoronix, welches mit git-stats zählte. Leider halte ich diesen Ansatz für mangelhaft, wie Sie auch in dem bereits oben verlinkten Kommentar nachlesen können.
Haben Sie meinen referenzierten Kommentar und meine darin enthaltene Zählung überhaupt nachvollzogen? Glauben Sie reißerischem Clickbait mehr als OpenHub, Coverity und meinen Ausführungen zusammen? Haben Sie selbst gezählt?
zu 5: Es gibt wesentlich minimalistischere Betriebssysteme als OpenBSD. Und warum eigentlich hat OpenBSD konsequenterweise keinen Microkernel wie etwa QNX? OpenBSD setzt auch im Jahr 2019 immer noch auf einem monolithischen Kernel auf. Welchen "Entwurfsgrundsätzen von UNIX-Systemen" entspricht das? Warum kritisieren Sie OpenBSD nicht für Software aus dem Basissystem, die nicht unter Linux läuft (alles, was BSD-spezifische Features wie strl*, explicit_bzero, BSDAuth, unveil, pledge, pf etc. nutzt)? LibreSSL und OpenSSH mussten auch auf portiert werden. Siehe auch getentropy/getrandom, was effektiv erst mit Verzögerung und Detailunterschieden unter Linux implementiert worden ist.
Diese Grundsätze sind zwar historisch gerechtfertigt, aber stoßen inzwischen seit Jahrzenten an ihre Grenzen des Möglichen. Grund dafür ist bspw. die zweite Regel Doug McIlroys, bzw. die dritte Peter H. Salus.
Und an welchen Punkten genau verstößt systemd diese Regeln grundlos? Was wären funktionell oder abstrakt gleichmächtige Alternativen?
zu 6: Mode interessiert mich nicht. Den Begriff der Diktatur habe ich nicht verwendet. Sie formulierten den Appell "Bitte besinnt euch der Entwurfsgrundsätzen von UNIX-Systemen.", was einerseits einer Forderung und andererseits einer Kritik gleichkommt. Ob Sie gerne etwas bestimmen wollen würden, weiß ich nicht, aber es liest sich für mich so.
Wenn Sie etwas kritisieren und Änderung fordern, aber nicht einmal Skizzen eines Alternativvorschlags vorweisen können, wie kann man sich davon überzeugen, dass Ihre Forderungen überhaupt realistisch sind? Ist ein zu systemd gleichmächtiges Pendant, welches sich stringent an die "Entwurfsgrundsätze von UNIX-Systemen" hält und gleichzeitig mehrere Systeme unterstützt, real umsetzbar? Wie groß wäre der Aufwand? Und wird der seinem Nutzen gerecht? Sind nicht schon viele Versuch dieser Art gescheitert? (Siehe uselessd; Ziel war es systemd aufs init zu reduzieren und auf andere libc-Implementierungen und Systeme wie die BSDs zu portieren. Es gab auch weitere ähnliche Versuche deren Namen mir allerdings entfallen sind, aber heute alle gescheitert sein dürften.) Andere Projekte wie eudev und elogind (Forks von Teilen von systemd) kommen an ihre Grenzen und erfüllen respektiv nur eine Teilmenge an Features. Da sind diese Fragen und Einwände wohl gerechtfertigt, oder?
Im Rahmen der Meinungsfreiheit hat jeder das Recht alles mögliche zu fordern.
Ja, natürlich. Nur was wollen Sie mir damit sagen? Dass ich Ihre falschen Fakten, oberflächlichen Argumente, Schlussfolgerungen und Darstellungen einfach so stehen lassen soll?
Sie müssen Ihre Aussagen auch belastbar stützen können. Da müssen Sie sich schon "fiese" Einwände und Fragen gefallen lassen. Mit Meinungsfreiheit hat das nichts zu tun. Eher mit eingeschnappter Leberwurst, die nur wenige stichhaltige Gegenargumente auffahren kann und deshalb in einem Streit der Ansichten unterliegt.
Mit diesen Unterstellungen und dem ad hominem Angriff am Ende ("man kann Sie nicht ernst nehmen") disqualifiziert sich der Beitrag eigentlich selbst.
Nett, dass Sie das "Andernfalls" aus "Andernfalls man kann Sie nicht ernst nehmen" gekonnt ausgelassen haben. Demnach hatte ich es allein Ihren Reaktionen auf meinen Kommentar überlassen, ob man Sie tatsächlich nicht ernst nehmen könnte. Nicht einmal für ein "[...] man kann Sie nicht ernst nehmen." hat es gereicht... ein Schelm, wer dabei Böses denkt. Um ein "ad hominem" handelt es sich in jedem Fall nicht, da er sich auf den Inhalt Ihrer Kommentare bezieht.
Meine "Unterstellung" sind jedenfalls nicht haltlos. Sie haben ihre Berechtigung, welche ich bereits angeführt habe.
--- Ich gehe davon aus, dass Sie mit meinen Darstellungen in den Punkten übereinstimmen, auf die Sie nicht näher eingegangen sind.
Ja, systemd kann mehr als ein minimales Init. Und genau das ist das Problem in sicherheitsrelevanten use cases.
Nicht nur da. Dieses Zeugs scheint in jede Ritze des Systems auszubreiten - wie ein Pilzmyzel. Mir wird das immer suspekter.
Zu 6: Seit wann ist es eigentlich Mode dass, sobald jemand etwas fordert, unterstellt wird man wolle etwas bestimmen, eine (Meinungs-)Diktatur errichten o.ä. Im Rahmen der Meinungsfreiheit hat jeder das Recht alles mögliche zu fordern.
Nicht aufregen, das ist zum Glück noch keine Mode, sondern nur die *Masche* bestimmter Leute hier. Der eine oder andere kommt mir dabei vor wie eine Art Chimäre aus Korinthenspalter und Aal.
Nicht aufregen, das ist zum Glück noch keine Mode, sondern nur die *Masche* bestimmter Leute hier. Der eine oder andere kommt mir dabei vor wie eine Art Chimäre aus Korinthenspalter und Aal.
Na aber, das geht in großen Schritten in Richtung ad hominem - merken Sie selber, nicht?
An welcher Stelle habe ich unterstellt, jemand würde eine (Meinungs-)Diktatur errichten wollen, oder suggeriert, jemandem das Recht auf Meinungsfreiheit einzuschränken oder zu versagen?
Von Verfluchtnochmal_5987108 am So, 3. November 2019 um 23:42 #
Mit Verlaub aber wer 2019 meint initscripts wären so toll was security betrifft ist ziemlich ahnungslos!
Dank systemd laufen meine httpd seit Jahren mit cgroups, seccomp, namespaces und vor allem eingeschränkten capabilities
Bedeutet: Auch der Master Prozess läuft nicht als root, die capability um auf 80/443 lauschen zu können ist mit einer Zeile im systemd unit erledigt und voila der exploit aus einem worker per scoreboard root Rechte zu erlangen hat hier auch vor dem Update nicht funktioniert
Ähnliches galt vor Jahren als sich mysql/mariadb über ein dämliches config snippet im datadir austricksen ließ, genauer gesagt mysqld_safe was ich hier 2011 durch systemd ersetzt habe weil das Tool nicht mehr gebraucht wird
Geh weg mit deinen Märchen von wegen sysvinit und security, ich könnte dir Bücher schreiben von ganzen Angriffsklassen die ich über die Jahre durch das Lesen von systemd Manuals und konsequentem Einsatz der Möglichkeiten einfach ausgeschlossen habe
Vieles davon ist mit einem initscript schlichtweg nicht machbar oder ein extrem fragiles Konstrukt
Von SecurityGuy am Fr, 8. November 2019 um 11:23 #
Klassisches Beispiel einer Strohmann-Argumentation. Mit keinem Wort wird zuvor erwähnt, dass sysvinit besonders sicher wäre. Erwähnt werden "minimale Inits" - namentlich OpenRC und das BSD-Init von OpenBSD.
systemd ist von der Fre Software Foundation nicht zertifiziert. Man sollte immer auf freie Software zurückgreifen, in diesem Fall also auf GNU Shepherd.
Ich weiß nicht, was genau "zertifiziert" in diesem Zusammenhang bedeuten soll, und welchen Bezug Ihr Argument in dieser Diskussion hätte. Könnten Sie das bitte konkretisieren?
systemd steht unter der LGPL v2.1+, siehe hier und hier. Damit ist es "frei" im Sinne der Definition der FSF.
Ja, aber das erklärt erstens nicht den Zusammenhang zur vorangehenden Diskussion, und zweitens was man tun soll, wenn die GNU-Software Feature X nicht unterstützt? Konkreter: Was tun wenn GNU dmd Feature X von systemd nicht unterstützt? Als Hausaufgaben Sie dürfen sich selbst ein solches X aussuchen
1. SUSE gehört schon lange nicht mehr zu Novell. Nach der Übernahme Novells durch die Attachmate Group (2011) wurden Novell und SUSE wieder zu eigenständigen Unternehmen entflechtet. Das blieb auch nach der Übernahme Attachmates von Micro Focus International (2014) so bestehen. Seit Mitte 2018 gehört SUSE dem Investor EQT Partners AB. Quelle
2. Woher stammt die Zahl von 1,2M LoC? Laut OpenHub handelt es sich eher um circa 660k Zeilen Quelltext, davon sind etwa knapp 500k Zeilen Quelltext (davon ~385k C-Code und ~65k XML z.B. für hwdb(7)), der Rest sind Kommentare (~44k Zeilen) und Leerzeilen (~130k).
Andere Zahlen finden sich auch hier. Ich verweise auch auf meine eigens durchgeführte Zählung von Ende Mai.
3. SLOC ist eine Metrik mit geringer Aussagekraft. Was genau wollen Sie damit messen?
4. Die Anzahl der Zeilen Quelltext im Quellverzeichnis von systemd bewältigen weitaus mehr Aufgaben als init (oder SysV). Da ist bspw. udev enthalten, sowie viele rein optionale Komponenten (systemd-boot, journald, journalctl, networkd, networkctl, resolved, resolvectl, timesyncd, ...).
Ja, der Teil für init ist bei systemd fetter als bei SysV zuvor, insbesondere der init-Prozess. Er kann aber auch sehr viel mehr. Die Fähigkeiten mögen zwar nicht immer notwendig oder gewünscht sein, aber das ist der Preis "universeller" Systeme. Zudem hat man die Option der reichhaltigen Alternativen.
5. Was genau sind Ihrer Meinung nach die "Entwurfsgrundsätze von UNIX-Systemen"? Entspricht der Linux-Kernel und das Entwicklungsmodell der BSDs (alle entwickeln ihren eigenen monolithischen Kernel samt Basissystem ohne Ansprüche auf absolute Minimalität, Orthogonalität, Portabilität oder Unabhängigkeit projektspezifischer Features) auch diesen Grundsätzen?
6. Warum sollen sich die anderen auf Ihre Maximen "besinnen"? Mit welchem Recht machen Sie Ihre Forderungen zum Anspruch geltend? Statt zu nörgeln, habe Sie die Möglichkeit, es besser zu machen. Tragen Sie systemd bei und verbessern es, forken Sie es nach Ihrem gusto und beglücken ggf. den Rest der Welt damit, falls es Ihnen recht ist, oder aber finanzieren, unterstützen, entwickeln, nutzen und/oder verbreiten Sie eine Alternative zu systemd. Sie haben die Wahl.
7. zu "Ein Werkzeug für eine Aufgabe und nicht die eierlegenden Wollmilchsau, [...]": Genau die wollen die wichtigsten Kunden Red Hats aber scheinbar haben. Und was nun?
Und welche Teile von systemd sollen Ihrer Meinung nach technisch strikter separiert werden? Oder geht es Ihnen eher um das Entwicklungsmodell (Monorepo) oder die politische Komponente?
8. "[...], die keiner außer den Erstellern mehr überblickt.": Sie suggerieren hier implizit etwas, dass Sie nicht belegen können. Es scheinen viele talentierte und gut bezahlte Administratoren zu existieren, die sich mit ihren Werkzeugen auskennen, sonst würden ständig mittlere digitale Infrastrukturkatastrophen entstehen, die sich allein auf systemd zurückführen ließen und von denen der Otto Normalverbraucher etwas mitkriegen würde. Zudem würde niemand diese Administratoren oder die Software-Lizenzen bezahlen wollen.
Haben Sie quantitative Belege für Ihre Aussage?
Ergo: Bitte reden Sie Klartext, streuen Sie keine falschen Fakten ein, belegen Sie Ihre Fakten und Argumente, und ziehen Sie bitte logische Schlüsse und Vergleiche bevor Sie voreilig urteilen. Nur das kann als solide Grundlage für eine erstrebenswert fruchtbare Diskussion gewertet werden. Andernfalls kann man Sie nicht ernst nehmen.
Eine Punkt hatte ich vergessen. Also:
9. Viele Zeilen Quelltext in systemd sind auch mit Absicht geschrieben worden, das Entwickeln und Warten von traditionell unixoiden daemons zu vereinfachen. Daher auch die services aus der Begriffswelt von systemd. Die Verwaltung mehrerer Prozesses eines Dienstes, das traditionelle double-forking, die Abhängigkeiten, die Race-Conditions, das Neustarten, die Init-Skripte, das Isolieren und der dafür in jedem daemon notwendige zusätzliche Code wurden mit systemd angegangen und zu großen Teilen abgedeckt.
Vielen Quelltextzeilen systemds stehen also ein Vielfaches an obsoleten Quelltextzeilen in systemd-Diensten gegenüber.
Zu 2:
Systemd Now Has More Than 1.2 Million Lines of Code
Ja, systemd kann mehr als ein minimales Init. Und genau das ist das Problem in sicherheitsrelevanten use cases.
Zu 5: zumindest OpenBSD befolgt die Grundsätze der Minimalität. Im übrigen sind die Grundsätze von Unix recht gut definiert: https://en.wikipedia.org/wiki/Unix_philosophy
Zu 6: Seit wann ist es eigentlich Mode dass, sobald jemand etwas fordert, unterstellt wird man wolle etwas bestimmen, eine (Meinungs-)Diktatur errichten o.ä. Im Rahmen der Meinungsfreiheit hat jeder das Recht alles mögliche zu fordern.
Mit diesen Unterstellungen und dem ad hominem Angriff am Ende ("man kann Sie nicht ernst nehmen") disqualifiziert sich der Beitrag eigentlich selbst.
zu 2:
Die von Ihnen genannte Sekundärquelle ist wie auch der Pro-Linux Artikel, zu welchem ich bereits indirekt mit dem Verweis auf meinen Kommentar mit eigener Zählung verwies, mehr oder minder reißerischer Clickbait. Die Primärquelle ist Phoronix, welches mit git-stats zählte. Leider halte ich diesen Ansatz für mangelhaft, wie Sie auch in dem bereits oben verlinkten Kommentar nachlesen können.
Haben Sie meinen referenzierten Kommentar und meine darin enthaltene Zählung überhaupt nachvollzogen? Glauben Sie reißerischem Clickbait mehr als OpenHub, Coverity und meinen Ausführungen zusammen? Haben Sie selbst gezählt?
zu 5:
Es gibt wesentlich minimalistischere Betriebssysteme als OpenBSD. Und warum eigentlich hat OpenBSD konsequenterweise keinen Microkernel wie etwa QNX? OpenBSD setzt auch im Jahr 2019 immer noch auf einem monolithischen Kernel auf. Welchen "Entwurfsgrundsätzen von UNIX-Systemen" entspricht das? Warum kritisieren Sie OpenBSD nicht für Software aus dem Basissystem, die nicht unter Linux läuft (alles, was BSD-spezifische Features wie strl*, explicit_bzero, BSDAuth, unveil, pledge, pf etc. nutzt)? LibreSSL und OpenSSH mussten auch auf portiert werden. Siehe auch getentropy/getrandom, was effektiv erst mit Verzögerung und Detailunterschieden unter Linux implementiert worden ist.
Diese Grundsätze sind zwar historisch gerechtfertigt, aber stoßen inzwischen seit Jahrzenten an ihre Grenzen des Möglichen. Grund dafür ist bspw. die zweite Regel Doug McIlroys, bzw. die dritte Peter H. Salus.
Und an welchen Punkten genau verstößt systemd diese Regeln grundlos? Was wären funktionell oder abstrakt gleichmächtige Alternativen?
zu 6: Mode interessiert mich nicht. Den Begriff der Diktatur habe ich nicht verwendet. Sie formulierten den Appell "Bitte besinnt euch der Entwurfsgrundsätzen von UNIX-Systemen.", was einerseits einer Forderung und andererseits einer Kritik gleichkommt. Ob Sie gerne etwas bestimmen wollen würden, weiß ich nicht, aber es liest sich für mich so.
Wenn Sie etwas kritisieren und Änderung fordern, aber nicht einmal Skizzen eines Alternativvorschlags vorweisen können, wie kann man sich davon überzeugen, dass Ihre Forderungen überhaupt realistisch sind? Ist ein zu systemd gleichmächtiges Pendant, welches sich stringent an die "Entwurfsgrundsätze von UNIX-Systemen" hält und gleichzeitig mehrere Systeme unterstützt, real umsetzbar? Wie groß wäre der Aufwand? Und wird der seinem Nutzen gerecht? Sind nicht schon viele Versuch dieser Art gescheitert? (Siehe uselessd; Ziel war es systemd aufs init zu reduzieren und auf andere libc-Implementierungen und Systeme wie die BSDs zu portieren. Es gab auch weitere ähnliche Versuche deren Namen mir allerdings entfallen sind, aber heute alle gescheitert sein dürften.) Andere Projekte wie eudev und elogind (Forks von Teilen von systemd) kommen an ihre Grenzen und erfüllen respektiv nur eine Teilmenge an Features. Da sind diese Fragen und Einwände wohl gerechtfertigt, oder?
Ja, natürlich. Nur was wollen Sie mir damit sagen? Dass ich Ihre falschen Fakten, oberflächlichen Argumente, Schlussfolgerungen und Darstellungen einfach so stehen lassen soll?Sie müssen Ihre Aussagen auch belastbar stützen können. Da müssen Sie sich schon "fiese" Einwände und Fragen gefallen lassen. Mit Meinungsfreiheit hat das nichts zu tun. Eher mit eingeschnappter Leberwurst, die nur wenige stichhaltige Gegenargumente auffahren kann und deshalb in einem Streit der Ansichten unterliegt.
Nett, dass Sie das "Andernfalls" aus "Andernfalls man kann Sie nicht ernst nehmen" gekonnt ausgelassen haben. Demnach hatte ich es allein Ihren Reaktionen auf meinen Kommentar überlassen, ob man Sie tatsächlich nicht ernst nehmen könnte. Nicht einmal für ein "[...] man kann Sie nicht ernst nehmen." hat es gereicht... ein Schelm, wer dabei Böses denkt.Um ein "ad hominem" handelt es sich in jedem Fall nicht, da er sich auf den Inhalt Ihrer Kommentare bezieht.
Meine "Unterstellung" sind jedenfalls nicht haltlos. Sie haben ihre Berechtigung, welche ich bereits angeführt habe.
---
Ich gehe davon aus, dass Sie mit meinen Darstellungen in den Punkten übereinstimmen, auf die Sie nicht näher eingegangen sind.
Nicht nur da. Dieses Zeugs scheint in jede Ritze des Systems auszubreiten - wie ein Pilzmyzel. Mir wird das immer suspekter.
Nicht aufregen, das ist zum Glück noch keine Mode, sondern nur die *Masche* bestimmter Leute hier. Der eine oder andere kommt mir dabei vor wie eine Art Chimäre aus Korinthenspalter und Aal.
An welcher Stelle habe ich unterstellt, jemand würde eine (Meinungs-)Diktatur errichten wollen, oder suggeriert, jemandem das Recht auf Meinungsfreiheit einzuschränken oder zu versagen?
Mit Verlaub aber wer 2019 meint initscripts wären so toll was security betrifft ist ziemlich ahnungslos!
Dank systemd laufen meine httpd seit Jahren mit cgroups, seccomp, namespaces und vor allem eingeschränkten capabilities
Bedeutet: Auch der Master Prozess läuft nicht als root, die capability um auf 80/443 lauschen zu können ist mit einer Zeile im systemd unit erledigt und voila der exploit aus einem worker per scoreboard root Rechte zu erlangen hat hier auch vor dem Update nicht funktioniert
Ähnliches galt vor Jahren als sich mysql/mariadb über ein dämliches config snippet im datadir austricksen ließ, genauer gesagt mysqld_safe was ich hier 2011 durch systemd ersetzt habe weil das Tool nicht mehr gebraucht wird
Geh weg mit deinen Märchen von wegen sysvinit und security, ich könnte dir Bücher schreiben von ganzen Angriffsklassen die ich über die Jahre durch das Lesen von systemd Manuals und konsequentem Einsatz der Möglichkeiten einfach ausgeschlossen habe
Vieles davon ist mit einem initscript schlichtweg nicht machbar oder ein extrem fragiles Konstrukt
Klassisches Beispiel einer Strohmann-Argumentation. Mit keinem Wort wird zuvor erwähnt, dass sysvinit besonders sicher wäre. Erwähnt werden "minimale Inits" - namentlich OpenRC und das BSD-Init von OpenBSD.
systemd ist von der Fre Software Foundation nicht zertifiziert. Man sollte immer auf freie Software zurückgreifen, in diesem Fall also auf GNU Shepherd.
Ich weiß nicht, was genau "zertifiziert" in diesem Zusammenhang bedeuten soll, und welchen Bezug Ihr Argument in dieser Diskussion hätte. Könnten Sie das bitte konkretisieren?
systemd steht unter der LGPL v2.1+, siehe hier und hier. Damit ist es "frei" im Sinne der Definition der FSF.
Im Zweifelsfall soll man immer original GNU software verwenden, dann steht man auf der sicheren Seite.
Ja, aber das erklärt erstens nicht den Zusammenhang zur vorangehenden Diskussion, und zweitens was man tun soll, wenn die GNU-Software Feature X nicht unterstützt? Konkreter: Was tun wenn GNU dmd Feature X von systemd nicht unterstützt? Als Hausaufgaben Sie dürfen sich selbst ein solches X aussuchen
Von der FSF zertifiziert?
Hast du getrunken?