{"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\/es\/blog\/news\/inicziativa-po-sokrashheniyu-zavisimostej-u-libsystemd","title":{"rendered":"Iniciativa para reducir dependencias en libsystemd","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Entre los desarrolladores del gestor de sistema systemd se est\u00e1 discutiendo la cuesti\u00f3n de reducir las dependencias de la biblioteca libsystemd, que no solo se vincula a componentes de systemd, sino tambi\u00e9n a muchas aplicaciones externas. Por ejemplo, en Fedora, m\u00e1s de 150 paquetes utilizan libsystemd como dependencia. El iniciador de la discusi\u00f3n considera que la inclusi\u00f3n de bibliotecas externas adicionales en libsystemd, que no son controladas por los desarrolladores de systemd, aumenta significativamente la superficie de ataque en caso de compromiso de estas bibliotecas externas, tal como ocurri\u00f3 con la biblioteca liblzma. <\/p>\n
Adem\u00e1s de liblzma y glibc, en libsystemd tambi\u00e9n se cargan las bibliotecas libzstd, liblz4 y libgcrypt, siendo el mantenimiento de la seguridad de estas bibliotecas una tarea cr\u00edticamente importante. En libsystemd se proporciona acceso a 12 API b\u00e1sicas (sd-bus, sd-daemon, sd-device, sd-event, sd-hwdb, sd-id128, sd-journal, sd-login, sd-netlink, sd-network, sd-path y sd-resolve), y se plantea la situaci\u00f3n en la que una aplicaci\u00f3n que utiliza libsystemd solo para invocar la funci\u00f3n sd_notify para informar a systemd sobre un cambio de estado o sd_journal para registrar datos en el log, se vincula a todas las dem\u00e1s bibliotecas y controladores de API. Como soluci\u00f3n, se propone dividir libsystemd en varias bibliotecas independientes responsables de API espec\u00edficas, lo que permitir\u00eda cargar dependencias externas solo donde son necesarias. <\/p>\n
Los desarrolladores de systemd consideran que la divisi\u00f3n no es pr\u00e1ctica, ya que los controladores presentes en libsystemd est\u00e1n interrelacionados. La divisi\u00f3n requerir\u00eda un enorme trabajo y resultar\u00eda en una p\u00e9rdida de eficiencia o en la necesidad de duplicar el c\u00f3digo. Para reducir el uso de memoria en libsystemd, recientemente se tom\u00f3 la decisi\u00f3n de implementar la carga din\u00e1mica de las bibliotecas liblzma, libzstd y liblz4 mediante la llamada dlopen() en situaciones donde sus funciones son realmente necesarias. Un cambio similar se implementar\u00e1 a partir de la pr\u00f3xima versi\u00f3n para libgcrypt. <\/p>\n
Esta soluci\u00f3n ha sido objeto de cr\u00edticas, ya que en lugar de un enlace expl\u00edcito y obvio, la carga de bibliotecas externas ahora se realizar\u00e1 de manera impl\u00edcita, lo que complicar\u00e1 el diagn\u00f3stico, ya que no es evidente la conexi\u00f3n entre las llamadas API de libsystemd y la invocaci\u00f3n de funciones de bibliotecas externas. El simple cambio a la carga mediante dlopen() no cambia la arquitectura, sino que oculta los componentes externos de los mantenedores y usuarios. <\/p>\n
Lenart Pottering expres\u00f3 su desacuerdo categ\u00f3rico con la idea de dividir libsystemd en varias bibliotecas, ya que tal medida complicar\u00eda considerablemente el uso compartido de c\u00f3digo en systemd y requerir\u00eda trasladar todos los manejadores internos a la categor\u00eda de p\u00fablicos o compilar est\u00e1ticamente cada uno en cada biblioteca. En el primer caso, surgir\u00edan problemas para mantener la estabilidad de la API y los espacios de nombres, y en el segundo, se incremetar\u00eda el tama\u00f1o debido a la duplicaci\u00f3n de c\u00f3digo. <\/p>\n
La carga de bibliotecas externas solo seg\u00fan sea necesario, implementada para la pr\u00f3xima versi\u00f3n, es considerada por Leonard como una estrategia \u00f3ptima. Se sugiere resolver el problema de la complicaci\u00f3n para obtener informaci\u00f3n sobre las bibliotecas cargadas din\u00e1micamente a\u00f1adiendo campos adicionales a los archivos ELF con informaci\u00f3n sobre estas dependencias din\u00e1micas, que pueden ser manejadas por los depuradores y mostrarse en la salida de la utilidad readelf. <\/p>\n
En cuanto a la vinculaci\u00f3n de un gran n\u00famero de aplicaciones con libsystemd, Leonard recomend\u00f3 a los desarrolladores de aplicaciones que no intenten cargar libsystemd por una sola funci\u00f3n, sino que implementen el manejador de protocolos a nivel de aplicaci\u00f3n. Por ejemplo, la implementaci\u00f3n de la funcionalidad sd_notify() es bastante trivial y puede resumirse en unas pocas l\u00edneas de c\u00f3digo al utilizar sockets UNIX (AF_UNIX). Desde 2017, existe una implementaci\u00f3n aislada de sd_notify disponible para OpenSSH, y recientemente ha sido aceptada en la rama portable de OpenSSH 9.8, cuyo lanzamiento est\u00e1 previsto para mediados de verano. \n Fuente: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"