{"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\/novosti-interneta\/inicziativa-po-sokrashheniyu-zavisimostej-u-libsystemd","title":{"rendered":"Initiative zur Reduktion von Abh\u00e4ngigkeiten in libsystemd.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
In der Community der Systemverwaltungsentwickler von systemd wird \u00fcber die Reduzierung der Abh\u00e4ngigkeiten der Bibliothek libsystemd diskutiert, die nicht nur mit Komponenten von systemd verbunden ist, sondern auch mit vielen externen Anwendungen. Zum Beispiel verwenden in Fedora mehr als 150 Pakete libsystemd als Abh\u00e4ngigkeit. Der Initiator der Diskussion ist der Ansicht, dass die Einbeziehung zus\u00e4tzlicher externer Bibliotheken, die nicht von den Entwicklern von systemd kontrolliert werden, die Angriffsfl\u00e4che im Falle eines Kompromisses dieser externen Bibliotheken erheblich vergr\u00f6\u00dfert, \u00e4hnlich 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, wobei die Aufrechterhaltung der Sicherheit zu einer kritisch wichtigen Aufgabe wird. libsystemd bietet 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). Es kann Situationen geben, in denen eine Anwendung, die libsystemd beispielsweise nur f\u00fcr den Aufruf der Funktion sd_notify verwendet, um systemd \u00fcber Status\u00e4nderungen zu informieren, oder sd_journal, um Daten zu protokollieren, mit allen anderen Bibliotheken und API-Handlern verbunden wird. Als L\u00f6sung wird vorgeschlagen, libsystemd in mehrere separate Bibliotheken zu unterteilen, die f\u00fcr einzelne APIs verantwortlich sind, wodurch externe Abh\u00e4ngigkeiten nur dort geladen werden, wo sie erforderlich sind. <\/p>\n
Die Entwickler von systemd halten eine Trennung f\u00fcr unangemessen, da die in libsystemd vorhandenen Handler miteinander verkn\u00fcpft sind. Eine Trennung w\u00fcrde einen enormen Aufwand erfordern und entweder zu einem Effizienzverlust oder zu Code-Duplikation f\u00fchren. Um den Speicherverbrauch in libsystemd zu reduzieren, wurde k\u00fcrzlich eine \u00c4nderung beschlossen, die die dynamische Ladeimplementierung 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 umgesetzt. <\/p>\n
Eine solche Entscheidung wurde kritisiert, da anstelle einer klaren und direkten Verkn\u00fcpfung die Lade von Drittanbieterbibliotheken nun nicht mehr explizit erfolgt, was die Diagnose erschwert, da die Verbindung der API-Aufrufe von libsystemd mit den Aufrufen von Funktionen aus externen Bibliotheken nicht offensichtlich ist. Der \u00dcbergang zur Lade \u00fcber dlopen() ver\u00e4ndert an sich nicht die Architektur, sondern verbirgt lediglich externe Komponenten vor den Entwicklern und Nutzern. <\/p>\n
Leonard Pottering hat sich entschieden gegen die Idee ausgesprochen, libsystemd in mehrere Bibliotheken zu unterteilen, da dieser Schritt die gemeinsame Nutzung von Code in systemd erheblich erschweren w\u00fcrde. Dadurch m\u00fcsste man alle internen Handler entweder zu \u00f6ffentlichen machen oder sie separat in jede Bibliothek statisch kompilieren. Im ersten Fall ergeben sich Probleme bei der Aufrechterhaltung der API-Stabilit\u00e4t und der Namensr\u00e4ume, im zweiten Fall w\u00fcrde die Gr\u00f6\u00dfe aufgrund der Code-Duplikation steigen. <\/p>\n
F\u00fcr die n\u00e4chste Version umgesetzte, bedarfsgerechte Ladefunktion f\u00fcr externe Bibliotheken wird von Lenart als optimale Strategie angesehen. Das Problem, Daten \u00fcber dynamisch geladene Bibliotheken zu erhalten, soll durch das Hinzuf\u00fcgen zus\u00e4tzlicher Felder mit Informationen \u00fcber solche dynamischen Abh\u00e4ngigkeiten in ELF-Dateien gel\u00f6st werden, die von Debuggern verarbeitet und in der Ausgabe des Tools readelf angezeigt werden k\u00f6nnen. <\/p>\n
Was die Bindung von libsystemd an eine gro\u00dfe Anzahl von Anwendungen betrifft, riet Lennart den Anwendungsentwicklern, libsystemd nicht f\u00fcr eine einzelne Funktion zu laden, sondern einen Protokollhandler auf Anwendungsebene zu implementieren. Zum Beispiel ist die Implementierung der Funktionalit\u00e4t von sd_notify() relativ trivial und kann in wenigen Codezeilen unter Verwendung von UNIX-Sockets (AF_UNIX) erfolgen. Eine solche isolierte Implementierung von sd_notify ist seit 2017 f\u00fcr OpenSSH verf\u00fcgbar und wurde k\u00fcrzlich in den tragbaren Branch von OpenSSH 9.8 aufgenommen, dessen Ver\u00f6ffentlichung f\u00fcr die Mitte des Sommers geplant ist. \n Quelle: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"