A rendszerkezelő systemd fejlesztői között folyik a libsystemd könyvtár függőségeinek csökkentésével kapcsolatos diskurzus, amely nemcsak a systemd komponenseivel, hanem számos külső alkalmazással is kapcsolatban áll. Például a Fedora esetében több mint 150 csomag használja a libsystemd-t függőségeiként. A diskurzus kezdeményezője úgy véli, hogy a libsystemd-be integrált további külső könyvtárak, amelyeket a systemd fejlesztői nem ellenőriznek, jelentősen megnövelik a támadási felületet, ha a külső könyvtárak kompromittálódnak, ahogy ez a liblzma könyvtár esetében is történt.
A liblzma és glibc mellett a libsystemd-be betöltődnek a libzstd, liblz4 és libgcrypt könyvtárak is, amelyek biztonságának fenntartása kritikus feladattá válik. A libsystemd hozzáférést biztosít 12 alapvető API-hoz (sd-bus, sd-daemon, sd-device, sd-event, sd-hwdb, sd-id128, sd-journal, sd-login, sd-netlink, sd-network, sd-path és sd-resolve), és olyan helyzet áll elő, amikor egy alkalmazás, például a libsystemd-t csupán az sd_notify funkció hívására használja a systemd állapotváltozásának értesítésére, vagy az sd_journal-t az adatok naplózására, kapcsolatba kerül az összes többi könyvtárral és API kezelővel. Javaslatként merült fel, hogy a libsystemd-t több különálló könyvtárra bontsák, amelyek különböző API-kért felelősek, lehetővé téve a külső függőségek betöltését csak ahol szükséges.
A systemd fejlesztői nem találják célszerűnek a szétválasztást, mivel a libsystemd-ben található kezelők összefonódnak. A szétválasztás hatalmas munkát igényelne, és vagy hatékonysági veszteséget, vagy kódduplázási szükségességet eredményezne. A libsystemd memóriahasználatának csökkentése érdekében nemrégiben elfogadták a liblzma, libzstd és liblz4 dinamikus betöltésének megvalósítását dlopen() hívással olyan helyzetekben, amikor azok funkciói valóban szükségesek. Hasonló változtatást a következő kiadásban a libgcryptra is végrehajtanak.
Ez a megoldás kritikát váltott ki, mivel a nyilvánvaló és észlelhető kapcsolódás helyett a külső könyvtárak betöltése mostantól nem nyilvánvaló módon fog történni, ami megnehezíti a diagnosztikát, mivel nem egyértelmű a libsystemd API-hívásainak és a külső könyvtárból származó funkciók hívásainak kapcsolata. Maga a dlopen() használatára való áttérés nem változtatja meg az architektúrát, csupán elrejti a külső komponenseket a karbantartók és felhasználók elől.
Lenart Pottering hat entschieden, dass die Idee, libsystemd in mehrere Bibliotheken zu unterteilen, katastrophal ist, da dieser Schritt die gemeinsame Nutzung des Codes in systemd erheblich erschwert und alle internen Handler entweder in öffentliche umgewandelt oder separat statisch in jede Bibliothek kompiliert werden müssten. Im ersten Fall würden Probleme mit der Stabilität der API und den Namensräumen auftreten, während im zweiten Fall die Größe aufgrund von Code-Duplikationen zunehmen würde.
Die für die nächste Version implementierte bedarfsorientierte Ladefunktion externer Bibliotheken wird von Lenart als optimale Strategie angesehen. Um das Problem der Beschaffung von Informationen über dynamisch geladene Bibliotheken zu lösen, wird vorgeschlagen, zusätzliche Felder mit Informationen über diese dynamischen Abhängigkeiten in ELF-Dateien hinzuzufügen, die von Debuggern verarbeitet und in der Ausgabe des Tools readelf angezeigt werden können.
Was die Verknüpfung einer großen Anzahl von Anwendungen mit libsystemd betrifft, so empfahl Lenart den Anwendungsentwicklern, libsystemd nicht nur für eine Funktion zu laden, sondern den Protokoll-Handler auf Anwendungsebene umzusetzen. Zum Beispiel ist die Implementierung der Funktionalität von sd_notify() recht 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ür OpenSSH verfügbar und wurde kürzlich in den tragbaren Branch von OpenSSH 9.8 aufgenommen, dessen Veröffentlichung für Mitte Sommer geplant ist.
Forrás: opennet.ru
