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

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