Parmi les d\u00e9veloppeurs du gestionnaire de syst\u00e8mes systemd, une discussion est en cours sur la r\u00e9duction des d\u00e9pendances de la biblioth\u00e8que libsystemd, qui est li\u00e9e non seulement aux composants de systemd, mais aussi \u00e0 de nombreuses applications externes. Par exemple, dans Fedora, plus de 150 paquets utilisent libsystemd comme d\u00e9pendance. L'initiateur de la discussion estime que l'inclusion de biblioth\u00e8ques tierces suppl\u00e9mentaires dans libsystemd, qui ne sont pas contr\u00f4l\u00e9es par les d\u00e9veloppeurs de systemd, augmente consid\u00e9rablement la surface d'attaque en cas de compromission de ces biblioth\u00e8ques, comme cela a \u00e9t\u00e9 le cas avec la biblioth\u00e8que liblzma. <\/p>\n
En plus de liblzma et glibc, libsystemd charge \u00e9galement les biblioth\u00e8ques libzstd, liblz4 et libgcrypt, dont le maintien de la s\u00e9curit\u00e9 devient une t\u00e2che critique. libsystemd fournit un acc\u00e8s \u00e0 12 API de base (sd-bus, sd-daemon, sd-device, sd-event, sd-hwdb, sd-id128, sd-journal, sd-login, sd-netlink, sd-network, sd-path et sd-resolve) cr\u00e9ant une situation o\u00f9 une application, par exemple, utilisant libsystemd uniquement pour appeler la fonction sd_notify afin d'informer systemd d'un changement d'\u00e9tat ou sd_journal pour enregistrer des donn\u00e9es dans le journal, se lie \u00e0 toutes les autres biblioth\u00e8ques et gestionnaires d'API. Pour y rem\u00e9dier, il est propos\u00e9 de diviser libsystemd en plusieurs biblioth\u00e8ques distinctes, chacune responsable d'une API sp\u00e9cifique, ce qui permettrait de charger des d\u00e9pendances tierces uniquement lorsque cela est n\u00e9cessaire. <\/p>\n
Les d\u00e9veloppeurs de systemd estiment que cette s\u00e9paration n'est pas judicieuse, car les gestionnaires pr\u00e9sents dans libsystemd sont interconnect\u00e9s. La s\u00e9paration n\u00e9cessiterait un travail \u00e9norme et entra\u00eenerait soit une perte d'efficacit\u00e9, soit la n\u00e9cessit\u00e9 de dupliquer du code. Pour r\u00e9duire l'occupation m\u00e9moire dans libsystemd, un changement a r\u00e9cemment \u00e9t\u00e9 adopt\u00e9 avec la mise en \u0153uvre du chargement dynamique des biblioth\u00e8ques liblzma, libzstd et liblz4 via un appel \u00e0 dlopen(), dans des situations o\u00f9 leurs fonctions sont r\u00e9ellement n\u00e9cessaires. Un changement similaire sera \u00e9galement mis en \u0153uvre pour libgcrypt \u00e0 partir de la prochaine version. <\/p>\n
Cette d\u00e9cision a \u00e9t\u00e9 critiqu\u00e9e car, au lieu d'un lien explicite et manifeste, le chargement des biblioth\u00e8ques tierces sera d\u00e9sormais effectu\u00e9 de mani\u00e8re implicite, ce qui compliquera le diagnostic, car la liaison entre les appels d'API de libsystemd et les fonctions des biblioth\u00e8ques externes n'est pas \u00e9vidente. Le passage au chargement via dlopen() ne change pas l'architecture en soi, mais cache simplement les composants externes aux mainteneurs et aux utilisateurs. <\/p>\n
Lenart Pottering a exprim\u00e9 son d\u00e9saccord cat\u00e9gorique avec l'id\u00e9e de diviser libsystemd en plusieurs biblioth\u00e8ques, car cette d\u00e9marche compliquerait consid\u00e9rablement le partage de code dans systemd et n\u00e9cessiterait de convertir tous les gestionnaires internes en \u00e9l\u00e9ments publics ou de les compiler s\u00e9par\u00e9ment dans chaque biblioth\u00e8que. Dans le premier cas, des probl\u00e8mes de maintien de la stabilit\u00e9 de l'API et des espaces de noms surgiraient, tandis que dans le second cas, cela entra\u00eenerait une augmentation de taille due \u00e0 la duplication de code. <\/p>\n
La strat\u00e9gie mise en place pour le prochain lancement de chargement des biblioth\u00e8ques externes uniquement si n\u00e9cessaire est per\u00e7ue par Leonard comme une strat\u00e9gie optimale. Le probl\u00e8me de la complexit\u00e9 d'obtention des donn\u00e9es sur les biblioth\u00e8ques charg\u00e9es de mani\u00e8re dynamique est propos\u00e9 d'\u00eatre r\u00e9solu par l'ajout de champs suppl\u00e9mentaires dans les fichiers ELF contenant des informations sur ces d\u00e9pendances dynamiques, qui peuvent \u00eatre trait\u00e9es par les d\u00e9bogueurs et affich\u00e9es dans la sortie de l'outil readelf. <\/p>\n