{"id":114764,"date":"2024-04-03T12:25:48","date_gmt":"2024-04-03T10:25:48","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/inicziativa-po-sokrashheniyu-zavisimostej-u-libsystemd"},"modified":"2024-04-03T12:25:48","modified_gmt":"2024-04-03T10:25:48","slug":"inicziativa-po-sokrashheniyu-zavisimostej-u-libsystemd","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/news\/inicziativa-po-sokrashheniyu-zavisimostej-u-libsystemd","title":{"rendered":"Initiative zur Verringerung der Abh\u00e4ngigkeiten von libsystemd","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Unter den Entwicklern des Systemmanagers systemd wird die Frage diskutiert, die Abh\u00e4ngigkeiten der Bibliothek libsystemd zu verringern, die nicht nur mit den Komponenten von systemd, sondern auch mit vielen externen Anwendungen verbunden ist. Zum Beispiel verwenden in Fedora \u00fcber 150 Pakete libsystemd in ihren Abh\u00e4ngigkeiten. Der Initiator der Diskussion ist der Meinung, dass das Einbinden zus\u00e4tzlicher externer Bibliotheken in libsystemd, die nicht von den Entwicklern von systemd kontrolliert werden, die Angriffsfl\u00e4che im Fall einer Kompromittierung dieser externen Bibliotheken erheblich vergr\u00f6\u00dfert, wie es bei der Bibliothek liblzma der Fall war. <\/p>\n
Neben liblzma und glibc werden in libsystemd auch die Bibliotheken libzstd, liblz4 und libgcrypt geladen, deren Sicherheit kritisch wichtig wird. In libsystemd gibt es Zugriff auf 12 grundlegende APIs (sd-bus, sd-daemon, sd-device, sd-event, sd-hwdb, sd-id128, sd-journal, sd-login, sd-netlink, sd-network, sd-path und sd-resolve), was zu der Situation f\u00fchrt, dass eine Anwendung, die beispielsweise libsystemd nur f\u00fcr den Aufruf der Funktion sd_notify zur Benachrichtigung von systemd \u00fcber den Statuswechsel oder sd_journal zur Protokollierung von Daten nutzt, mit all den anderen Bibliotheken und API-Handlern verbunden ist. Als L\u00f6sung wird vorgeschlagen, libsystemd in mehrere separate Bibliotheken aufzuteilen, die jeweils f\u00fcr eine bestimmte API zust\u00e4ndig sind, sodass externe Abh\u00e4ngigkeiten nur dort geladen werden, wo sie ben\u00f6tigt werden. <\/p>\n
Die Entwickler von systemd halten die Trennung f\u00fcr nicht sinnvoll, da die in libsystemd vorhandenen Handler miteinander verkn\u00fcpft sind. Eine Trennung w\u00fcrde einen enormen Aufwand erfordern und entweder zu einem Verlust an Effizienz oder zu einer Notwendigkeit der Code-Duplikation f\u00fchren. Um den Speicherbedarf in libsystemd zu reduzieren, wurde k\u00fcrzlich eine \u00c4nderung beschlossen, die die dynamische Lade der Bibliotheken liblzma, libzstd und liblz4 mittels des Aufrufs dlopen() erm\u00f6glicht, wenn deren Funktionen tats\u00e4chlich ben\u00f6tigt werden. Eine \u00e4hnliche \u00c4nderung wird ab der n\u00e4chsten Version auch f\u00fcr libgcrypt implementiert. <\/p>\n
Eine solche L\u00f6sung wurde kritisiert, da die Ladezeiten von Drittanbieterbibliotheken nun nicht mehr offensichtlich und sichtbar sind, was die Diagnostik erschwert, da die Verbindung zwischen den API-Aufrufen von libsystemd und den Funktionsaufrufen aus externen Bibliotheken nicht offensichtlich ist. Der Wechsel zum Laden \u00fcber dlopen() \u00e4ndert an sich nicht die Architektur, sondern verbirgt lediglich externe Komponenten vor Entwicklern und Benutzern. <\/p>\n
Lenart Poettering hat entschieden entschieden, die Idee einer Aufspaltung von libsystemd in mehrere Bibliotheken abzulehnen, da dieser Schritt die gemeinsame Nutzung des Codes in systemd erheblich erschweren und erfordern w\u00fcrde, dass alle internen Handler als \u00f6ffentlich deklariert oder separat statisch in jede Bibliothek kompiliert werden m\u00fcssen. Im ersten Fall w\u00fcrden Probleme mit der Stabilit\u00e4t der API und den Namensr\u00e4umen auftreten, w\u00e4hrend im zweiten Fall die Gr\u00f6\u00dfe aufgrund von Code-Duplikationen zunehmen w\u00fcrde. <\/p>\n
Die f\u00fcr die n\u00e4chste Version implementierte bedarfsorientierte Ladeweise externer Bibliotheken wird von Lenart als optimale Strategie betrachtet. Um das Problem zu l\u00f6sen, dass Informationen \u00fcber dynamisch geladene Bibliotheken schwer zu beschaffen sind, wird vorgeschlagen, in ELF-Dateien zus\u00e4tzliche Felder mit Informationen \u00fcber solche dynamischen Abh\u00e4ngigkeiten hinzuzuf\u00fcgen, die von Debuggern verarbeitet und in der Ausgabe des Tools readelf angezeigt werden k\u00f6nnen. <\/p>\n
Was die Bindung von libsystemd an viele Anwendungen betrifft, so empfahl Lenart den Entwicklern, libsystemd nicht nur f\u00fcr eine Funktion zu laden, sondern einen Protokollhandler auf Anwendungsebene zu implementieren. Zum Beispiel ist die Implementierung der Funktionalit\u00e4t von sd_notify() ziemlich trivial und kann in wenigen Zeilen Code unter Verwendung von UNIX-Sockets (AF_UNIX) erledigt werden. Eine derartige eigenst\u00e4ndige Implementierung von sd_notify ist seit 2017 f\u00fcr OpenSSH verf\u00fcgbar und wurde vor kurzem in die tragbare Version von OpenSSH 9.8 aufgenommen, deren Ver\u00f6ffentlichung f\u00fcr Mitte des Sommers geplant ist. \n Quelle: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"