Помимо 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 для записи данных в лог, связывается со всеми остальными библиотеками и обработчиками API. В качестве выхода предлагается разделить libsystemd на несколько отдельных библиотек, отвечающих за отдельные API, что позволит подгружать сторонние зависимости только там, где они необходимы.
Разработчики systemd считают разделение не целесообразным, так как
вынесенные в libsystemd обработчики взаимосвязаны и их разделение потребует огромной работы и приведёт либо к потере эффективности, либо к необходимости дублирования кода. Для сокращения занимаемой памяти в libsystemd недавно принято изменение c реализацией динамической загрузки библиотек liblzma, libzstd и liblz4 при помощи вызова dlopen(), в ситуациях когда их функции действительно необходимы. Аналогичное изменение начиная со следующего выпуска будет реализовано и для libgcrypt.
Подобное решение стало объектом критики, так как вместо явного и заметного связывания, загрузка сторонних библиотек теперь будет производиться не явно, что усложнит диагностику, так как не очевидна связь API-вызовов libsystemd c вызовом функций из внешних библиотек. Сам по себе переход на загрузку при помощи dlopen() не меняет архитектуру, а лишь скрывает внешние компоненты от сопровождающих и пользователей.
Ленарт Поттеринг выразил категорическое несогласие с идеей разделения libsystemd на несколько библиотек, так как такой шаг существенно усложнит совместное использование кода в systemd и потребует перевести все внутренние обработчик в разряд публичных или отдельно статически компилировать их с каждой библиотекой. В первом случае возникнут проблемы с поддержанием стабильности API и пространствами имён, а во втором к увеличению размера из-за дублирования кода.
Реализованная для следующего выпуска загрузка внешних библиотек только по необходимости воспринимается Ленартом как оптимальная стратегия. Проблему с усложнением получения данных о динамически загружаемых библиотеках предлагается решить через добавление в файлы ELF дополнительных полей с информацией о подобных динамических зависимостях, которые могут обрабатываться отладчиками и показыватсья в выводе утилиты readelf.
Что касается связывания c libsystemd большим числа приложений, то
Ленарт порекомендовал не пытаться загружать libsystemd ради одной функции, а реализовать обработчик протокола на уровне приложения. Например, для реализация функциональности sd_notify() достаточно тривиальна и может уложиться в несколько строк кода при использовании UNIX-сокетов (AF_UNIX). Например, подобная обособленная реализация sd_notify с 2017 года доступна для OpenSSH и на днях принята в состав переносимой ветки OpenSSH 9.8, релиз которой намечен на середину лета.
Источник: http://www.opennet.ru/opennews/art.shtml?num=60912