p align="justify"> Серед розробників системного менеджера systemd ведеться обговорення питання скорочення залежностей у бібліотеки libsystemd, яка пов'язується не тільки з компонентами systemd, але і з багатьма зовнішніми додатками. Наприклад, у Fedora більше 150 пакетів використовують libsystemd у залежностях. Ініціатор обговорення вважає, що підтягування в libsystemd додаткових сторонніх бібліотек, які не контролюють розробники systemd, суттєво збільшує поверхню атаки у разі компрометації сторонніх бібліотек, як це сталося з бібліотекою liblzma.
Крім liblzma і glibc, у libsystemd також завантажуються бібліотеки libzstd, liblz4 і libgcrypt, підтримка безпеки в яких стає критично важливим завданням. У libsystemd надається доступ до 12 базових API (sd-bus, sd-daemon, sd-device, sd-event, sd-hwdb, sd-id128, sd-journal, sd-login, sd-netlink, sd-network, sd -path і sd-resolve) і виникає ситуація, коли додаток, наприклад, використовує libsystemd тільки заради виклику функції sd_notify для інформування systemd про зміну стану або sd_journal для запису даних у лог, зв'язується з іншими бібліотеками і обробниками API. В якості виходу пропонується розділити libsystemd на кілька окремих бібліотек, що відповідають за окремі API, що дозволить підвантажувати сторонні залежності лише там, де вони потрібні.
Розробники systemd вважають поділ не доцільним, оскільки присутні в libsystemd обробники взаємопов'язані. Поділ вимагатиме величезної роботи і призведе або до втрати ефективності, або до необхідності дублювання коду. Для скорочення пам'яті в libsystemd нещодавно прийнято зміну з реалізацією динамічного завантаження бібліотек liblzma, libzstd і liblz4 за допомогою виклику dlopen(), у ситуаціях коли їх функції дійсно необхідні. Аналогічна зміна з наступного випуску буде реалізована і для libgcrypt.
Подібне рішення стало об'єктом критики, тому що замість явного і помітного зв'язування, завантаження сторонніх бібліотек тепер проводитиметься не явно, що ускладнить діагностику, оскільки не очевидний зв'язок API-дзвінків libsystemd з викликом функцій із зовнішніх бібліотек. Сам собою перехід на завантаження за допомогою dlopen() не змінює архітектуру, а лише приховує зовнішні компоненти від супроводжуючих і користувачів.
Ленарт Поттерінг висловив категоричну незгоду з ідеєю поділу libsystemd на кілька бібліотек, оскільки такий крок суттєво ускладнить спільне використання коду в systemd і вимагатиме перевести всі внутрішні обробники в розряд публічних або окремо статично вкомпілювати їх у кожну бібліотеку. У першому випадку виникнуть проблеми з підтриманням стабільності API та просторами імен, а в другому – до збільшення розміру через дублювання коду.
Реалізоване для наступного випуску завантаження зовнішніх бібліотек лише в разі необхідності сприймається Ленартом як оптимальна стратегія. Проблему з ускладненням отримання даних про бібліотеки, що динамічно завантажуються, пропонується вирішити через додавання до файлів ELF додаткових полів з інформацією про подібні динамічні залежності, які можуть оброблятися налагоджувачами і показуватися у виведенні утиліти readelf.
Що стосується зв'язування з libsystemd великої кількості додатків, то Ленарт порекомендував розробникам додатків не намагатися завантажувати libsystemd заради однієї функції, а реалізувати обробник протоколу на рівні програми. Наприклад, реалізація функціональності sd_notify() досить тривіальна і може вкластися в кілька рядків коду під час використання UNIX-сокетів (AF_UNIX). Подібна відокремлена реалізація sd_notify з 2017 року доступна для OpenSSH і днями прийнята до складу гілки OpenSSH 9.8, що переноситься, реліз якої намічений на середину літа.
Джерело: opennet.ru
