{"id":114764,"date":"2024-04-03T12:25:48","date_gmt":"2024-04-03T10:25:48","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/inicziativa-po-sokrashheniyu-zavisimostej-u-libsystemd"},"modified":"2024-04-03T12:25:48","modified_gmt":"2024-04-03T10:25:48","slug":"inicziativa-po-sokrashheniyu-zavisimostej-u-libsystemd","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/news\/inicziativa-po-sokrashheniyu-zavisimostej-u-libsystemd","title":{"rendered":"Iniciativa para reduzir depend\u00eancias no libsystemd","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Entre os desenvolvedores do gerenciador de sistema systemd, h\u00e1 uma discuss\u00e3o sobre a redu\u00e7\u00e3o das depend\u00eancias da biblioteca libsystemd, que est\u00e1 vinculada n\u00e3o apenas aos componentes do systemd, mas tamb\u00e9m a muitos aplicativos externos. Por exemplo, no Fedora, mais de 150 pacotes usam libsystemd como depend\u00eancia. O iniciador da discuss\u00e3o acredita que a inclus\u00e3o de bibliotecas externas adicionais na libsystemd, que n\u00e3o s\u00e3o controladas pelos desenvolvedores do systemd, aumenta significativamente a superf\u00edcie de ataque em caso de comprometimento das bibliotecas externas, como ocorreu com a biblioteca liblzma. <\/p>\n
Al\u00e9m da liblzma e glibc, a libsystemd tamb\u00e9m carrega as bibliotecas libzstd, liblz4 e libgcrypt, e a manuten\u00e7\u00e3o da seguran\u00e7a dessas bibliotecas se torna uma tarefa cr\u00edtica. A libsystemd oferece acesso a 12 APIs principais (sd-bus, sd-daemon, sd-device, sd-event, sd-hwdb, sd-id128, sd-journal, sd-login, sd-netlink, sd-network, sd-path e sd-resolve), criando uma situa\u00e7\u00e3o em que um aplicativo que utiliza a libsystemd apenas para chamar a fun\u00e7\u00e3o sd_notify para informar ao systemd sobre altera\u00e7\u00f5es de estado ou sd_journal para registrar dados no log, acaba se vinculando a todas as outras bibliotecas e manipuladores de API. Como solu\u00e7\u00e3o, sugere-se dividir a libsystemd em v\u00e1rias bibliotecas separadas, respons\u00e1veis por APIs individuais, o que permitir\u00e1 carregar depend\u00eancias externas apenas onde forem necess\u00e1rias. <\/p>\n
Os desenvolvedores do systemd consideram a divis\u00e3o inadequada, uma vez que os manipuladores presentes na libsystemd s\u00e3o interdependentes. A divis\u00e3o exigiria um enorme trabalho e resultaria em perda de efici\u00eancia ou na necessidade de duplica\u00e7\u00e3o de c\u00f3digo. Para reduzir o uso de mem\u00f3ria na libsystemd, foi recentemente aprovada uma altera\u00e7\u00e3o implementando o carregamento din\u00e2mico das bibliotecas liblzma, libzstd e liblz4 por meio da chamada dlopen(), em situa\u00e7\u00f5es em que suas fun\u00e7\u00f5es s\u00e3o realmente necess\u00e1rias. Uma altera\u00e7\u00e3o semelhante ser\u00e1 implementada na pr\u00f3xima vers\u00e3o para a libgcrypt. <\/p>\n
Essa solu\u00e7\u00e3o foi alvo de cr\u00edticas, pois, em vez de um v\u00ednculo expl\u00edcito e not\u00e1vel, o carregamento de bibliotecas externas agora ser\u00e1 feito de forma impl\u00edcita, o que complicar\u00e1 o diagn\u00f3stico, pois a rela\u00e7\u00e3o entre as chamadas de API da libsystemd e as chamadas de fun\u00e7\u00f5es de bibliotecas externas n\u00e3o ser\u00e1 clara. A transi\u00e7\u00e3o para o carregamento por meio da dlopen() em si n\u00e3o altera a arquitetura, mas apenas oculta os componentes externos dos desenvolvedores e usu\u00e1rios. <\/p>\n
Lenart Poettering expressou uma discord\u00e2ncia categ\u00f3rica em rela\u00e7\u00e3o \u00e0 ideia de dividir o libsystemd em v\u00e1rias bibliotecas, pois essa mudan\u00e7a complicaria significativamente o compartilhamento de c\u00f3digo no systemd e exigiria que todos os manipuladores internos fossem transformados em p\u00fablicos ou que fossem estaticamente compilados em cada biblioteca. No primeiro caso, surgiriam problemas para manter a estabilidade da API e dos namespaces, e no segundo, a um aumento de tamanho devido \u00e0 duplica\u00e7\u00e3o de c\u00f3digo. <\/p>\n
A carga de bibliotecas externas somente quando necess\u00e1ria, implementada para a pr\u00f3xima vers\u00e3o, \u00e9 vista por Lenart como uma estrat\u00e9gia ideal. A proposta para resolver o problema da complexidade na obten\u00e7\u00e3o de dados sobre bibliotecas carregadas dinamicamente \u00e9 adicionar campos adicionais nos arquivos ELF com informa\u00e7\u00f5es sobre essas depend\u00eancias din\u00e2micas, que podem ser processadas por depuradores e exibidas na sa\u00edda da ferramenta readelf. <\/p>\n
Quanto \u00e0 vincula\u00e7\u00e3o da libsystemd a um grande n\u00famero de aplicativos, Lenart recomendou que desenvolvedores n\u00e3o tentem carregar a libsystemd apenas para uma fun\u00e7\u00e3o, mas implementem o manipulador de protocolo no n\u00edvel do aplicativo. Por exemplo, a implementa\u00e7\u00e3o da funcionalidade sd_notify() \u00e9 bastante trivial e pode ser condensada em algumas linhas de c\u00f3digo utilizando sockets UNIX (AF_UNIX). Uma implementa\u00e7\u00e3o isolada de sd_notify dispon\u00edvel desde 2017 para OpenSSH foi recentemente aceita na vers\u00e3o port\u00e1til do OpenSSH 9.8, cujo lan\u00e7amento est\u00e1 previsto para meados do ver\u00e3o. \n Fonte: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"