Wśród twórców menedżera systemu systemd toczy się dyskusja na temat zmniejszenia zależności biblioteki libsystemd, która łączy nie tylko komponenty systemd, ale także wiele aplikacji zewnętrznych. Na przykład w Fedorze ponad 150 pakietów używa libsystemd w swoich zależnościach. Inicjator dyskusji uważa, że dodanie do libsystemd dodatkowych bibliotek innych firm, które nie są kontrolowane przez programistów systemd, znacznie zwiększa powierzchnię ataku w przypadku naruszenia bezpieczeństwa bibliotek innych firm, tak jak miało to miejsce w przypadku biblioteki liblzma.
Oprócz liblzma i glibc, libsystemd ładuje także libzstd, liblz4 i libgcrypt, których bezpieczeństwo staje się krytyczne. libsystemd zapewnia dostęp do 12 podstawowych API (sd-bus, sd-daemon, sd-device, sd-event, sd-hwdb, sd-id128, sd-journal, sd-login, sd-netlink, sd-network, sd - path i sd-resolve) i powstaje sytuacja, gdy aplikacja np. korzystająca z libsystemd tylko w celu wywołania funkcji sd_notify w celu poinformowania systemd o zmianie stanu lub sd_journal w celu zapisania danych do logu, łączy się ze wszystkimi innymi bibliotekami i Programy obsługi API. Jako wyjście proponuje się podzielenie libsystemd na kilka oddzielnych bibliotek odpowiedzialnych za oddzielne API, co umożliwi ładowanie zależności innych firm tylko tam, gdzie są potrzebne.
Twórcy systemd uważają separację za niewłaściwą, ponieważ procedury obsługi obecne w libsystemd są ze sobą połączone. Dzielenie wymagałoby dużo pracy i skutkowałoby albo utratą wydajności, albo koniecznością powielania kodu. Aby zmniejszyć zużycie pamięci, w bibliotece libsystemd zmieniono ostatnio sposób dynamicznego ładowania bibliotek liblzma, libzstd i liblz4 za pomocą wywołania dlopen() w sytuacjach, gdy ich funkcje są rzeczywiście potrzebne. Podobna zmiana zostanie wprowadzona w libgcrypt począwszy od następnej wersji.
Decyzja ta stała się przedmiotem krytyki, ponieważ zamiast jawnego i zauważalnego linkowania, ładowanie bibliotek stron trzecich będzie teraz odbywało się w sposób niejawny, co skomplikuje diagnostykę, ponieważ połączenie wywołań API libsystemd z wywołaniami funkcji z bibliotek zewnętrznych nie jest oczywiste. Samo przejście na ładowanie za pomocą dlopen() nie zmienia architektury, a jedynie ukrywa komponenty zewnętrzne przed opiekunami i użytkownikami.
Lenart Pottering zdecydowanie nie zgodził się z pomysłem podziału libsystemd na kilka bibliotek, ponieważ takie posunięcie znacznie skomplikowałoby dzielenie kodu w systemd i wymagałoby upublicznienia wszystkich wewnętrznych procedur obsługi lub oddzielnej statycznej kompilacji ich do każdej biblioteki. W pierwszym przypadku wystąpią problemy z utrzymaniem stabilności API i przestrzeni nazw, a w drugim będzie on rósł w wyniku duplikacji kodu.
Zaimplementowane w następnej wersji ładowanie zewnętrznych bibliotek tylko wtedy, gdy jest to konieczne, jest postrzegane przez Lenarta jako optymalna strategia. Proponuje się rozwiązać problem rosnącej złożoności pozyskiwania danych o bibliotekach ładowanych dynamicznie poprzez dodanie do plików ELF dodatkowych pól z informacjami o takich dynamicznych zależnościach, które mogą być przetwarzane przez debuggery i pokazywane na wyjściu narzędzia readelf.
Jeśli chodzi o łączenie dużej liczby aplikacji z libsystemd, Lenart zalecił twórcom aplikacji, aby nie próbowali ładować libsystemd ze względu na jedną funkcję, ale zaimplementowali procedurę obsługi protokołu na poziomie aplikacji. Na przykład implementacja funkcji sd_notify() jest dość trywialna i można ją wykonać w kilku linijkach kodu w przypadku korzystania z gniazd UNIX (AF_UNIX). Podobna osobna implementacja sd_notify jest dostępna dla OpenSSH od 2017 roku, a niedawno została przyjęta w przenośnej gałęzi OpenSSH 9.8, której wydanie zaplanowano na połowę lata.
Źródło: opennet.ru
