Med razvijalci sistemskega upravitelja systemd poteka razprava o zmanjšanju odvisnosti knjižnice libsystemd, ki je povezana ne samo s komponentami systemd, ampak tudi mnogimi zunanjimi aplikacijami. Na primer, v Fedori več kot 150 paketov uporablja libsystemd v svojih odvisnostih. Pobudnik razprave meni, da vključitev dodatnih zunanjih knjižnic v libsystemd, ki jih ne nadzorujejo razvijalci systemd, bistveno povečuje površino napada v primeru kompromitacije zunanjih knjižnic, kot se je to zgodilo z knjižnico liblzma.
Poleg liblzma in glibc se v libsystemd nalagajo tudi knjižnice libzstd, liblz4 in libgcrypt, vzdrževanje varnosti katerih postaja kritična naloga. V libsystemd je na voljo dostop do 12 osnovnih API-jev (sd-bus, sd-daemon, sd-device, sd-event, sd-hwdb, sd-id128, sd-journal, sd-login, sd-netlink, sd-network, sd-path in sd-resolve), pri čemer pride do situacije, ko aplikacija, na primer, uporablja libsystemd samo za klic funkcije sd_notify za obveščanje systemd o spremembi stanja ali sd_journal za zapis podatkov v dnevnik, povezana z vsemi drugimi knjižnicami in obdelovalci API. Kot rešitev se predlaga razdelitev libsystemd na več ločenih knjižnic, ki odgovarjajo za posamezne API-je, kar bi omogočilo nalaganje zunanjih odvisnosti le tam, kjer so potrebne.
Razvijalci systemd menijo, da razdelitev ni smiselna, saj so obdelovalci, prisotni v libsystemd, medsebojno povezani. Razdelitev bi zahtevala ogromno dela in bi privedla bodisi do izgube učinkovitosti bodisi do potrebe po podvajanju kode. Za zmanjšanje zasedenosti pomnilnika je bil v libsystemd nedavno sprejet poseg z implementacijo dinamičnega nalaganja knjižnic liblzma, libzstd in liblz4 z uporabo klica dlopen(), v situacijah, ko so njihove funkcije resnično potrebne. Podoben poseg bo od naslednjega izida realiziran tudi za libgcrypt.
Takšna rešitev je bila predmet kritike, saj bo namesto očitnega in vidnega povezovanja nalaganje zunanjih knjižnic zdaj potekalo nejasno, kar bo otežilo diagnostiko, saj ni očitna povezava med API klici libsystemd in klici funkcij iz zunanjih knjižnic. Sam prehod na nalaganje z uporabo dlopen() ne spreminja arhitekture, ampak le skriva zunanje komponente pred vzdrževalci in uporabniki.
Lennart Poettering je izrazil ostro nasprotovanje ideji razdelitve libsystemd na več knjižnic, saj bi tak korak bistveno otežil skupno uporabo kode v systemd in bi zahteval, da se vsi notranji obdelovalniki prevedejo v javne ali pa jih je treba posebej statično vključiti v vsako knjižnico. V prvem primeru bi se pojavile težave s ohranjanjem stabilnosti API-ja in imenskimi prostori, v drugem pa bi se povečala velikost zaradi podvajanja kode.
Zunanje knjižnice, ki se nalagajo le po potrebi, predstavljajo optimalno strategijo, po mnenju Lennarta. O težavi, ki nastane pri pridobivanju podatkov o dinamično nalaganih knjižnicah, se predlaga rešitev z dodajanjem dodatnih polj v ELF datoteke s podatki o teh dinamičnih odvisnostih, ki jih lahko obdelujejo razhroščevalniki in se prikazujejo v izhodu orodja readelf.
Kar zadeva povezovanje velikega števila aplikacij s libsystemd, je Lennart priporočil razvijalcem aplikacij, naj ne poskušajo nalagati libsystemd zgolj zaradi ene funkcionalnosti, ampak naj implementirajo obdelovalnik protokola na ravni aplikacije. Na primer, implementacija funkcionalnosti sd_notify() je dovolj enostavna in lahko obsega le nekaj vrstic kode ob uporabi UNIX-socketov (AF_UNIX). Takšna izolirana implementacija sd_notify je od leta 2017 na voljo za OpenSSH in je bila nedavno sprejeta v prenosno vejo OpenSSH 9.8, katere izdaja je predvidena sredi poletja.
Izvor: opennet.ru
