Mes zhvilluesve të menaxherit të sistemit systemd po diskutohet për zvogëlimin e varësive të bibliotekës libsystemd, e cila lidhet jo vetëm me komponentët e systemd, por edhe me shumë aplikacione të jashtme. Për shembull, në Fedora më shumë se 150 paketa përdorin libsystemd si varësi. Iniciatori i diskutimit beson se përfshirja në libsystemd e biblioteka të jashtme që nuk kontrollohen nga zhvilluesit e systemd, rrit ndjeshëm sipërfaqen e sulmit në rastin e kompromitimit të bibliotekave të jashtme, ashtu siç ndodhi me bibliotekën liblzma.
Përveç liblzma dhe glibc, në libsystemd gjithashtu ngarkohen bibliotekat libzstd, liblz4 dhe libgcrypt, ruajtja e sigurisë së të cilave bëhet një detyrë kritike. Në libsystemd ofrohet qasje në 12 API-të bazë (sd-bus, sd-daemon, sd-device, sd-event, sd-hwdb, sd-id128, sd-journal, sd-login, sd-netlink, sd-network, sd-path dhe sd-resolve) dhe ndodh situata kur një aplikacion, për shembull, duke përdorur libsystemd vetëm për të thirrur funksionin sd_notify për të njoftuar systemd për ndryshimin e gjendjes ose sd_journal për të regjistruar të dhënat në log, lidhet me të gjitha bibliotekat dhe menaxherët e tjerë të API-ve. Si një zgjidhje, propozohet ndarja e libsystemd në disa biblioteka të veçanta, të përgjegjshme për API të veçanta, gjë që do të lejonte ngarkimin e varësive të jashtme vetëm atje ku janë të nevojshme.
Zhvilluesit e systemd e konsiderojnë ndarjen si të papërshtatshme, pasi trajtuesit e pranishëm në libsystemd janë të lidhur. Ndarja do të kërkonte një punë të madhe dhe do të shkaktonte ose humbjen e efikasitetit, ose nevojën për të dubluar kodin. Për të zvogëluar hapësirën e përdorur në libsystemd, së fundmi është miratuar një ndryshim me implementimin e ngarkimit dinamik të bibliotekave liblzma, libzstd dhe liblz4 përmes thirrjes dlopen(), në situatat kur funksionet e tyre janë me të vërtetë të nevojshme. Një ndryshim i ngjashëm do të implementohet gjithashtu që nga lëshimi i ardhshëm për libgcrypt.
Kjo zgjidhje është bërë objekt kritikash, pasi në vend të lidhjes së qartë dhe të dukshme, ngarkimi i bibliotekave të jashtme tani do të bëhet në mënyrë jo të qartë, gjë që do ta komplikohet diagnostikimin, pasi lidhja ndërmjet thirrjeve API të libsystemd dhe thirrjeve të funksioneve nga bibliotekat e jashtme nuk është e qartë. Kalimi për në ngarkimin përmes dlopen() nuk e ndryshon arkitekturën, por thjesht fsheh komponentët e jashtëm nga mbështetësit dhe përdoruesit.
Lenart Poettering shprehu mosdakordësi të prerë me idenë e ndarjes së libsystemd në disa biblioteka, pasi një hap i tillë do ta komplikohej ndjeshëm ndarjen e kodit në systemd dhe do të kërkonte që të gjithë trajtuesit e brendshëm të kaloheshin në kategorinë publike ose të kompiloheshin ndaras dhe statikisht në çdo bibliotekë. Në rastin e parë do të lindnin probleme në ruajtjen e stabilitetit të API-së dhe hapësirave të emrave, ndërsa në rastin e dytë do të kishte një rritje në madhësi për shkak të dublimit të kodit.
Ngarkesa e bibliotekave të jashtme sipas nevojës për lëshimin e ardhshëm perceptohet nga Lenart si një strategji optimale. Problemi i vështirësimit të marrjes së të dhënave për bibliotekat që ngarkohen dinamikisht propozohet të zgjidhet përmes shtimit të fushave të reja në skedarët ELF me informacion mbi këto varësi dinamike, të cilat mund të përpunohen nga debuggerat dhe të tregohen në daljen e utilitarit readelf.
Sa i përket lidhjes me libsystemd të një numri të madh aplikacionesh, Lenart rekomandoi zhvilluesve të aplikacioneve të mos përpiqen të ngarkojnë libsystemd për një funksion të vetëm, por të implementojnë trajtuesin e protokollit në nivelin e aplikacionit. Për shembull, implementimi i funksionalitetit sd_notify() është mjaft trivialisht dhe mund të realizohet me disa rreshta kodi duke përdorur soketat UNIX (AF_UNIX). Një implementim i tillë i veçantë i sd_notify është në dispozicion për OpenSSH që nga viti 2017 dhe para pak ditësh u miratua në degën portative të OpenSSH 9.8, lëshimi i së cilës planifikohet për mes të verës.
Burimi: opennet.ru
