Initsiatiiv libsystemd sõltuvuste vähendamiseks

Süsteemihalduri systemd arendajate seas arutatakse küsimust, kuidas vähendada libsystemd raamatukogu sõltuvusi, mis on seotud mitte ainult systemd komponentidega, vaid ka paljude väliste rakendustega. Näiteks Fedora's kasutavad rohkem kui 150 paketti libsystemd sõltuvusi. Arutelu algataja arvab, et lisanduvate kolmandate osapoolte raamatukogude, mida systemd arendajad ei kontrolli, toomine libsystemd-sse suurendab oluliselt rünnakupinda kolmandate osapoolte raamatukogude kompromiteerimise korral, nagu juhtus liblzma raamatukoguga.

Lisaks liblzmale ja glibc-le laaditakse libsystemd ka libzstd, liblz4 ja libgcrypt raamatukogud, mille turvalisuse tagamine on kriitilise tähtsusega. Libsystemd-s antakse juurdepääs 12 põhiteenusele (sd-bus, sd-daemon, sd-device, sd-event, sd-hwdb, sd-id128, sd-journal, sd-login, sd-netlink, sd-network, sd-path ja sd-resolve) ning olukord, kus rakendus, mis näiteks kasutab libsystemd-d ainult sd_notify funktsiooni kutsumiseks, et informeerida systemd-d oleku muutusest või sd_journal-i logisse andmete salvestamiseks, seondub kõigi teiste raamatukogude ja API töötlejatega. Üks lahendus on jagada libsystemd mitmeks eraldi raamatukoguks, mis vastutavad eraldi API-de eest, mis võimaldab tuua kolmandate osapoolte sõltuvusi ainult seal, kus neid on vaja.

Systemd arendajad ei pea jagamist otstarbekaks, kuna libsystemd-s olevad töötlejad on omavahel seotud. Jagamine nõuab tohutut tööd ja toob kas efektiivsuse kaotuse või koodi dubleerimise vajaduse. Libsystemd-s mäluhulga vähendamiseks võeti hiljuti kasutusele muudatus, et implementatsioonis laaditaks liblzma, libzstd ja liblz4 raamatukogusid dünaamiliselt läbi dlopen() kutsumise, juhul kui nende funktsioonid on tõeliselt vajalikud. Sarnane muudatus rakendatakse järgmisel väljaandel ka libgcrypt jaoks.

Selline lahendus on saanud kriitikaks, kuna selge ja märgatav seondumine on asendatud vähem nähtava kolmandate osapoolte raamatukogude laadimisega, mis raskendab diagnostikat, kuna libsystemd API-kutsumise ja välistest raamatukogudest funktsioonide kutsumise vaheline seos ei ole enam ilmne. Dlopen() kasutusele võtmine enda iseloomu ei muuda, vaid varjab lihtsalt väliseid komponente hooldajatelt ja kasutajatelt.

Lenart Pottering väljendas kindlat vastuolu ideele jagada libsystemd mitmeks teegiks, kuna see samm muudaks koodi ühiskasutamise oluliselt keerulisemaks ja nõuaks kõikide sisemiste töötlejate viimist avalikku staatusele või nende eraldi staatiliselt iga teegi sisse kompileerimist. Esimesel juhul tekivad probleemid API stabiilsuse ja nimede ruumidega, teisel juhul suurendab see suurust koodi dubleerimise tõttu.

Järgmiseks väljaandeks rakendatud välimiste teekide laadimine ainult vajaduse korral vaadatakse Lenarti poolt optimistlikult. Probleemi, millega kaasneb andmete saamise keerukus dünaamiliselt laaditud teekide osas, pakutakse lahendada, lisades ELF-failidesse täiendavaid välju teabe kohta sarnaste dünaamiliste sõltuvuste kohta, mida suudavad töödelda silurid ning mis kuvatakse utiliidi readelf väljundis.

Mis puudutab suurt hulka rakendusi, mis on seotud libsystemd-iga, siis soovitas Lenart rakenduste arendajatel mitte püüda laadida libsystemd-d ainult ühe funktsiooni pärast, vaid rakendada protokolli töötlejat rakenduse tasemel. Näiteks sd_notify() funktsionaalsuse rakendamine on piisavalt triviaalne ja võib mahtuda mõnesse koodireatesse, kasutades UNIX-sokette (AF_UNIX). Selline eraldi rakendus sd_notify on saadaval OpenSSH jaoks alates 2017. aastast ning hiljuti on see aktsepteeritud ülekantava haru OpenSSH 9.8 koosseisu, mille väljaandmine on planeeritud suve keskpaiku.

Allikas: opennet.ru