Инициативата за намаляване на зависимостите в libsystemd

Сред разработчиците на системния мениджър 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 е налична за OpenSSH от 2017 година и наскоро е приета в преносимата версия на OpenSSH 9.8, чийто релиз е насрочен за средата на лятото.

Източник: opennet.ru