{"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\/pl\/blog\/news\/inicziativa-po-sokrashheniyu-zavisimostej-u-libsystemd","title":{"rendered":"Inicjatywa redukcji zale\u017cno\u015bci w libsystemd","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
W\u015br\u00f3d tw\u00f3rc\u00f3w mened\u017cera systemowego systemd toczy si\u0119 dyskusja na temat zmniejszenia zale\u017cno\u015bci w bibliotece libsystemd, kt\u00f3ra jest powi\u0105zana nie tylko z komponentami systemd, ale tak\u017ce z wieloma zewn\u0119trznymi aplikacjami. Na przyk\u0142ad w Fedory ponad 150 pakiet\u00f3w wykorzystuje libsystemd w swoich zale\u017cno\u015bciach. Inicjator dyskusji uwa\u017ca, \u017ce w\u0142\u0105czenie dodatkowych zewn\u0119trznych bibliotek do libsystemd, kt\u00f3re nie s\u0105 kontrolowane przez deweloper\u00f3w systemd, znacznie zwi\u0119ksza powierzchni\u0119 ataku w przypadku kompromitacji tych zewn\u0119trznych bibliotek, tak jak mia\u0142o to miejsce z bibliotek\u0105 liblzma. <\/p>\n
Opr\u00f3cz liblzma i glibc w libsystemd \u0142aduj\u0105 si\u0119 r\u00f3wnie\u017c biblioteki libzstd, liblz4 i libgcrypt, a zapewnienie ich bezpiecze\u0144stwa staje si\u0119 kluczowym zadaniem. W libsystemd udost\u0119pniono dost\u0119p do 12 podstawowych API (sd-bus, sd-daemon, sd-device, sd-event, sd-hwdb, sd-id128, sd-journal, sd-login, sd-netlink, sd-network, sd-path i sd-resolve) i istnieje sytuacja, w kt\u00f3rej aplikacja, na przyk\u0142ad, korzystaj\u0105ca z libsystemd tylko w celu wywo\u0142ania funkcji sd_notify w celu poinformowania systemd o zmianie stanu lub sd_journal w celu zapisania danych w logu, \u0142\u0105czy si\u0119 ze wszystkimi innymi bibliotekami i obs\u0142ugami API. Proponuje si\u0119 podzia\u0142 libsystemd na kilka oddzielnych bibliotek, odpowiedzialnych za poszczeg\u00f3lne API, co pozwoli na za\u0142adowanie zewn\u0119trznych zale\u017cno\u015bci tylko tam, gdzie s\u0105 naprawd\u0119 potrzebne. <\/p>\n
Deweloperzy systemd uwa\u017caj\u0105, \u017ce podzia\u0142 nie jest celowy, poniewa\u017c wyst\u0119puj\u0105ce w libsystemd obs\u0142ugi s\u0105 ze sob\u0105 powi\u0105zane. Podzia\u0142 wymaga\u0142by ogromnej pracy i prowadzi\u0142by albo do utraty wydajno\u015bci, albo do konieczno\u015bci duplikacji kodu. W celu zmniejszenia zajmowanej pami\u0119ci w libsystemd niedawno wprowadzono zmian\u0119 z realizacj\u0105 dynamicznego \u0142adowania bibliotek liblzma, libzstd i liblz4 za pomoc\u0105 wywo\u0142ania dlopen(), w sytuacjach, gdy ich funkcje s\u0105 rzeczywi\u015bcie potrzebne. Podobna zmiana od nast\u0119pnej wersji zostanie wprowadzona r\u00f3wnie\u017c dla libgcrypt. <\/p>\n
Takie rozwi\u0105zanie sta\u0142o si\u0119 obiektem krytyki, poniewa\u017c zamiast jawnego i wyra\u017anego powi\u0105zania, \u0142adowanie zewn\u0119trznych bibliotek b\u0119dzie odbywa\u0107 si\u0119 teraz niejawnie, co utrudni diagnostyk\u0119, poniewa\u017c zwi\u0105zek wywo\u0142a\u0144 API libsystemd z wywo\u0142aniami funkcji z zewn\u0119trznych bibliotek nie b\u0119dzie oczywisty. Sam przej\u015bcie na \u0142adowanie za pomoc\u0105 dlopen() nie zmienia architektury, a jedynie ukrywa zewn\u0119trzne komponenty przed utrzymuj\u0105cymi i u\u017cytkownikami. <\/p>\n
Leonard P\u00f6ttering stanowczo sprzeciwi\u0142 si\u0119 pomys\u0142owi podzia\u0142u libsystemd na kilka bibliotek, poniewa\u017c taki krok znacznie utrudni\u0142by wsp\u00f3\u0142dzielenie kodu w systemd i wymaga\u0142by przekwalifikowania wszystkich wewn\u0119trznych handler\u00f3w do kategorii publicznych lub oddzielnego statycznego skompilowania ich do ka\u017cdej biblioteki. W pierwszym przypadku pojawi\u0105 si\u0119 problemy z utrzymaniem stabilno\u015bci API i przestrzeni nazw, a w drugim - zwi\u0119kszenie rozmiaru z powodu duplikacji kodu. <\/p>\n
Zaimplementowane w nast\u0119pnej wersji \u0142adowanie zewn\u0119trznych bibliotek tylko w razie potrzeby jest postrzegane przez Lenarta jako optymalna strategia. Problem z komplikacjami przy pozyskiwaniu danych o dynamicznie \u0142adowanych bibliotekach proponuje si\u0119 rozwi\u0105za\u0107 poprzez dodanie do plik\u00f3w ELF dodatkowych p\u00f3l z informacjami o takich dynamicznych zale\u017cno\u015bciach, kt\u00f3re mog\u0105 by\u0107 przetwarzane przez debugery i pokazywane w wynikach narz\u0119dzia readelf. <\/p>\n
Je\u015bli chodzi o powi\u0105zanie z libsystemd du\u017cej liczby aplikacji, Lenart zaleci\u0142 tw\u00f3rcom aplikacji, aby nie pr\u00f3bowali \u0142adowa\u0107 libsystemd tylko w celu jednej funkcji, a zamiast tego zrealizowali przetwornik protoko\u0142u na poziomie aplikacji. Na przyk\u0142ad, implementacja funkcjonalno\u015bci sd_notify() jest wystarczaj\u0105co trywialna i mo\u017ce zmie\u015bci\u0107 si\u0119 w kilku linijkach kodu przy u\u017cyciu gniazd UNIX (AF_UNIX). Tego rodzaju odosobniona implementacja sd_notify od 2017 roku jest dost\u0119pna dla OpenSSH i niedawno zosta\u0142a przyj\u0119ta do przeno\u015bnej ga\u0142\u0119zi OpenSSH 9.8, kt\u00f3rej wydanie planowane jest na po\u0142ow\u0119 lata. \n \u0179r\u00f3d\u0142o: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"