{"id":114764,"date":"2024-04-03T12:25:48","date_gmt":"2024-04-03T10:25:48","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/inicziativa-po-sokrashheniyu-zavisimostej-u-libsystemd"},"modified":"2024-04-03T12:25:48","modified_gmt":"2024-04-03T10:25:48","slug":"inicziativa-po-sokrashheniyu-zavisimostej-u-libsystemd","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sl\/blog\/news\/inicziativa-po-sokrashheniyu-zavisimostej-u-libsystemd","title":{"rendered":"Iniciativa za zmanj\u0161anje odvisnosti pri libsystemd","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Med razvijalci sistemskega upravitelja systemd poteka razprava o zmanj\u0161anju odvisnosti knji\u017enice libsystemd, ki je povezana ne samo s komponentami systemd, ampak tudi mnogimi zunanjimi aplikacijami. Na primer, v Fedori ve\u010d kot 150 paketov uporablja libsystemd v svojih odvisnostih. Pobudnik razprave meni, da vklju\u010ditev dodatnih zunanjih knji\u017enic v libsystemd, ki jih ne nadzorujejo razvijalci systemd, bistveno pove\u010duje povr\u0161ino napada v primeru kompromitacije zunanjih knji\u017enic, kot se je to zgodilo z knji\u017enico liblzma. <\/p>\n
Poleg liblzma in glibc se v libsystemd nalagajo tudi knji\u017enice libzstd, liblz4 in libgcrypt, vzdr\u017eevanje varnosti katerih postaja kriti\u010dna 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 \u010demer pride do situacije, ko aplikacija, na primer, uporablja libsystemd samo za klic funkcije sd_notify za obve\u0161\u010danje systemd o spremembi stanja ali sd_journal za zapis podatkov v dnevnik, povezana z vsemi drugimi knji\u017enicami in obdelovalci API. Kot re\u0161itev se predlaga razdelitev libsystemd na ve\u010d lo\u010denih knji\u017enic, ki odgovarjajo za posamezne API-je, kar bi omogo\u010dilo nalaganje zunanjih odvisnosti le tam, kjer so potrebne. <\/p>\n
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\u010dinkovitosti bodisi do potrebe po podvajanju kode. Za zmanj\u0161anje zasedenosti pomnilnika je bil v libsystemd nedavno sprejet poseg z implementacijo dinami\u010dnega nalaganja knji\u017enic liblzma, libzstd in liblz4 z uporabo klica dlopen(), v situacijah, ko so njihove funkcije resni\u010dno potrebne. Podoben poseg bo od naslednjega izida realiziran tudi za libgcrypt. <\/p>\n
Tak\u0161na re\u0161itev je bila predmet kritike, saj bo namesto o\u010ditnega in vidnega povezovanja nalaganje zunanjih knji\u017enic zdaj potekalo nejasno, kar bo ote\u017eilo diagnostiko, saj ni o\u010ditna povezava med API klici libsystemd in klici funkcij iz zunanjih knji\u017enic. Sam prehod na nalaganje z uporabo dlopen() ne spreminja arhitekture, ampak le skriva zunanje komponente pred vzdr\u017eevalci in uporabniki. <\/p>\n
Lenart Pottering je izrazi\u0142 kategoryczny sprzeciw wobec pomys\u0142u podzia\u0142u libsystemd na kilka bibliotek, poniewa\u017c taki krok znacznie skomplikuje wsp\u00f3\u0142dzielenie kodu w systemd i wymusi przekszta\u0142cenie wszystkich wewn\u0119trznych handler\u00f3w w publiczne lub ich oddzielne statyczne skompilowanie w ka\u017cdej bibliotece. W pierwszym przypadku pojawi\u0105 si\u0119 problemy z utrzymaniem stabilno\u015bci API i przestrzeni nazw, a w drugim \u2014 zwi\u0119kszy si\u0119 rozmiar z powodu duplikacji kodu. <\/p>\n
Zunanje knji\u017enice, ki se nalagajo le po potrebi, predstavljajo optimalno strategijo, po mnenju Lennarta. O te\u017eavi, ki nastane pri pridobivanju podatkov o dinami\u010dno nalaganih knji\u017enicah, se predlaga re\u0161itev z dodajanjem dodatnih polj v ELF datoteke s podatki o teh dinami\u010dnih odvisnostih, ki jih lahko obdelujejo razhro\u0161\u010devalniki in se prikazujejo v izhodu orodja readelf. <\/p>\n
Kar zadeva povezovanje velikega \u0161tevila aplikacij s libsystemd, je Lennart priporo\u010dil razvijalcem aplikacij, naj ne posku\u0161ajo 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\u0161na 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. \n Izvor: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"