Onder ontwikkelaars van de systeembeheerder systemd is er discussie over het verminderen van afhankelijkheden van de bibliotheek libsystemd, die niet alleen aan systemd-componenten, maar ook aan veel externe applicaties is gekoppeld. Bijvoorbeeld, in Fedora gebruiken meer dan 150 pakketten libsystemd als afhankelijkheid. De initiatiefnemer van de discussie gelooft dat het integreren van extra externe bibliotheken in libsystemd, die niet onder controle staan van de ontwikkelaars van systemd, de aanvalsoppervlakte aanzienlijk vergroot in het geval van compromis van externe bibliotheken, zoals dat gebeurde met de bibliotheek liblzma.
Naast liblzma en glibc worden in libsystemd ook de bibliotheken libzstd, liblz4 en libgcrypt geladen, waarbij het waarborgen van de veiligheid een kritiek belangrijke taak wordt. In libsystemd is er toegang tot 12 basis-API's (sd-bus, sd-daemon, sd-device, sd-event, sd-hwdb, sd-id128, sd-journal, sd-login, sd-netlink, sd-network, sd-path en sd-resolve) en er ontstaat een situatie waarin een applicatie, bijvoorbeeld die libsystemd alleen gebruikt om de functie sd_notify aan te roepen om systemd te informeren over een statuswijziging of sd_journal voor het registreren van gegevens in de log, zich verbindt met alle andere bibliotheken en API-handlers. Als oplossing wordt voorgesteld om libsystemd te splitsen in verschillende aparte bibliotheken, elk verantwoordelijk voor aparte API's, zodat externe afhankelijkheden alleen daar kunnen worden geladen waar ze nodig zijn.
De ontwikkelaars van systemd beschouwen splitsing als onpraktisch, omdat de handlers in libsystemd met elkaar verbonden zijn. Splitsing zou enorme inspanningen vereisen en zou ofwel leiden tot verlies van efficiĆ«ntie, ofwel tot de noodzaak om code te dupliceren. Om het geheugenverbruik in libsystemd te verminderen, is onlangs een wijziging goedgekeurd met de implementatie van dynamische laadbibliotheken liblzma, libzstd en liblz4 via de aanroep dlopen(), in situaties waarin hun functies echt nodig zijn. Een vergelijkbare wijziging zal vanaf de volgende release ook worden geĆÆmplementeerd voor libgcrypt.
Deze oplossing is bekritiseerd, omdat in plaats van een duidelijke en zichtbare koppeling, de laadprocedure voor externe bibliotheken nu impliciet zal zijn, wat het diagnosticeren bemoeilijkt, aangezien de verbinding tussen API-aanroepen van libsystemd en aanroepen van functies uit externe bibliotheken niet duidelijk is. De overstap naar laden via dlopen() verandert de architectuur op zich niet, maar verbergt alleen de externe componenten voor de onderhouders en gebruikers.
Leonard Potttering heeft zijn categorische onenigheid geuit met het idee om libsystemd op te splitsen in verschillende bibliotheken, aangezien deze stap het delen van code binnen systemd aanzienlijk zou bemoeilijken en zou vereisen dat alle interne handlers worden omgezet naar publieke of afzonderlijk statisch in elke bibliotheek worden gecompileerd. In het eerste geval zouden er problemen ontstaan met het handhaven van API-stabiliteit en namespaces, en in het tweede geval zou dit leiden tot een toename van de grootte door code duplicatie.
De oplossing voor het volgende uitgave die externe bibliotheken alleen indien nodig laadt, wordt door Leonard als de optimale strategie beschouwd. Het probleem van het bemoeilijken van het verkrijgen van gegevens over dynamisch geladen bibliotheken wordt voorgesteld op te lossen door extra velden met informatie over dergelijke dynamische afhankelijkheden toe te voegen aan ELF-bestanden, die door debuggers kunnen worden verwerkt en kunnen worden weergegeven in de uitvoer van de tool readelf.
Wat betreft de binding van libsystemd aan een groot aantal applicaties, raadde Leonard ontwikkelaars aan om libsystemd niet te laden voor Ć©Ć©n functie, maar om een protocolhandler op applicatieniveau te implementeren. Bijvoorbeeld, de implementatie van de functionaliteit sd_notify() is vrij triviaal en kan in slechts enkele regels code worden gerealiseerd met behulp van UNIX-sockets (AF_UNIX). Een dergelijke afzonderlijke implementatie van sd_notify is sinds 2017 beschikbaar voor OpenSSH en onlangs goedgekeurd in de draagbare tak van OpenSSH 9.8, welke release is gepland voor het midden van de zomer.
Bron: opennet.ru
