Bland systemd-udviklere er der en diskussion om at reducere afhængighederne i bibliotekerne libsystemd, som ikke kun er bundet til systemd-komponenter, men også til mange eksterne applikationer. For eksempel bruger over 150 pakker i Fedora libsystemd som afhængighed. Initiativtageren til diskussionen mener, at at trække ekstra tredjepartsbiblioteker ind i libsystemd, som ikke kontrolleres af systemd-udviklerne, væsentligt øger angrebsoverfladen i tilfælde af, at tredjepartsbibliotekerne kompromitteres, som det skete med biblioteket liblzma.
Udover liblzma og glibc indlæses bibliotekerne libzstd, liblz4 og libgcrypt også i libsystemd, og opretholdelse af sikkerheden i disse bliver en kritisk opgave. Libsystemd giver adgang til 12 grundlæggende API'er (sd-bus, sd-daemon, sd-device, sd-event, sd-hwdb, sd-id128, sd-journal, sd-login, sd-netlink, sd-network, sd-path og sd-resolve), hvilket fører til en situation, hvor en applikation, for eksempel kun bruger libsystemd for at kalde funktionen sd_notify for at informere systemd om statusændringer, eller sd_journal for at registrere data i loggen, bliver bundet til alle de øvrige biblioteker og API-håndterere. Som en løsning foreslås det at opdele libsystemd i flere separate biblioteker, der hver især tager sig af specifikke API'er, hvilket gør det muligt kun at indlæse tredjepartsafhængigheder, hvor de er nødvendige.
Systemd-udviklerne mener, at en opdeling er uhensigtsmæssig, da de eksisterende håndterere i libsystemd er indbyrdes forbundne. En opdeling vil kræve enormt arbejde og enten føre til effektivitetstab eller nødvendiggøre duplikering af kode. For at reducere det beskedne pladsforbrug i libsystemd er der for nylig vedtaget en ændring med implementering af dynamisk indlæsning af bibliotekerne liblzma, libzstd og liblz4 ved hjælp af kaldet dlopen(), i situationer, hvor deres funktioner virkelig er nødvendige. En lignende ændring vil blive implementeret for libgcrypt med den næste udgivelse.
Denne løsning har været genstand for kritik, da indlæsning af tredjepartsbiblioteker nu vil ske implicit, hvilket komplicerer diagnosticeringen, da forbindelsen mellem API-kald fra libsystemd og kald af funktioner fra eksterne biblioteker ikke er åbenbar. Selve overgangen til indlæsning ved hjælp af dlopen() ændrer ikke arkitekturen, men skjuler blot de eksterne komponenter for vedligeholdere og brugere.
Lenart Pottering udtrykte sin kategoriske uenighed med idéen om at opdele libsystemd i flere biblioteker, da et sådant skridt vil komplicere delingen af koden i systemd væsentligt og kræve, at alle interne behandlere enten bliver offentlige eller statisk kompileres ind i hvert bibliotek. I det første tilfælde vil der opstå problemer med at opretholde stabiliteten af API'er og navnerum, og i det andet vil det føre til en stigning i størrelsen på grund af kode-duplikering.
Den implementering, der er planlagt til den næste udgave, hvor eksterne biblioteker kun indlæses efter behov, opfattes af Lenart som en optimal strategi. Problemet med kompliceringen af at hente data om dynamisk indlæste biblioteker foreslås løst ved at tilføje yderligere felter i ELF-filerne med information om sådanne dynamiske afhængigheder, som kan behandles af debuggere og vises i output fra readelf-værktøjet.
Når det kommer til at binde et stort antal applikationer til libsystemd, anbefalede Lenart applikationsudviklere ikke at forsøge at indlæse libsystemd for en enkelt funktion, men at implementere en protokolbehandler på applikationsniveau. For eksempel er implementeringen af funktionaliteten sd_notify() temmelig triviel og kan udføres på et par linjer kode ved brug af UNIX-sokler (AF_UNIX). En sådan adskilt implementering af sd_notify har været tilgængelig for OpenSSH siden 2017 og er for nylig blevet optaget i den bærbare gren af OpenSSH 9.8, hvis udgivelse er planlagt til midten af sommeren.
Kilde: opennet.ru
