systemd 259: Soporte Musl, run0 empower y adiĆ³s a System V

Puntos clave:
  • Soporte parcial para Musl libc (requiere configuraciĆ³n manual en Meson).
  • run0 --empower permite acciones privilegiadas sin cambiar el UID de usuario.
  • DeprecaciĆ³n confirmada de scripts System V y aumento de requisitos (Kernel 5.10+).
  • libsystemd ahora carga librerĆ­as externas mediante dlopen() para reducir dependencias.
  • El almacenamiento de Journal ahora es 'persistente' por defecto.
David Y. Naranjo

4 minutos

systemd

DespuĆ©s de poco mĆ”s de tres meses de desarrollo, se ha dado a conocer el lanzamiento de la nueva versiĆ³n de systemd 259. Esta actualizaciĆ³n introduce cambios en la arquitectura del sistema, destacando la apertura hacia bibliotecas estĆ”ndar alternativas, una gestiĆ³n de privilegios mĆ”s rigurosa y un endurecimiento de los requisitos tĆ©cnicos para futuras versiones.

Uno de los movimientos mĆ”s comentados en este ciclo es la transiciĆ³n hacia una mayor modularidad y la limpieza de dependencias heredadas, preparando el terreno para un ecosistema de Linux que se aleja definitivamente de los estĆ”ndares de dĆ©cadas pasadas.

Principales novedades de systemd 259

La nueva versiĆ³n systemd 259 se destaca por ser la primera versiĆ³n en aƱadir compatibilidad parcial con Musl, la biblioteca estĆ”ndar de C popular en distribuciones ligeras y entornos embebidos. Esta integraciĆ³n se gestiona a travĆ©s de la opciĆ³n libc en el sistema de compilaciĆ³n Meson. Sin embargo, debido a que Musl no implementa la funcionalidad NSS (Name Service Switch), varios componentes de systemd permanecen desactivados en esta configuraciĆ³n.

Entre las ausencias notables al compilar con Musl se encuentran nss-systemd, nss-resolve, systemd-homed, systemd-userdbd y el parƔmetro DynamicUser. AdemƔs, no es posible ejecutar systemd-nspawn sin privilegios bajo esta biblioteca. Los desarrolladores han advertido que el mantenimiento de este soporte en versiones futuras dependerƔ de la demanda de la comunidad y de la estabilidad de las capas de compatibilidad adicionales que se desarrollen.

Otra de las novedades que presenta la nueva versiĆ³n es en la utilidad run0, diseƱada como una alternativa moderna y segura a sudo, la cual ha recibido la nueva opciĆ³n ā€“empower. Esta funciĆ³n permite iniciar sesiones con privilegios elevados sin necesidad de cambiar el identificador de usuario (UID) a root.

Ademas de ello, en lugar de delegar el control total mediante el cambio de usuario, ā€“empower utiliza indicadores de capacidades del kernel, como CAP_SYS_ADMIN, para otorgar los permisos estrictamente necesarios para realizar llamadas al sistema privilegiadas. AdemĆ”s, los procesos resultantes se integran en un grupo especĆ­fico que les otorga acceso a acciones de Polkit, manteniendo una separaciĆ³n de privilegios mĆ”s robusta que el modelo tradicional de sudo.

El fin de una era: AdiĆ³s a System V y nuevos requisitos

systemd 259 marca el comienzo del fin para la compatibilidad con los scripts de servicio de System V. Se ha anunciado que en la prĆ³xima versiĆ³n se eliminarĆ”n definitivamente componentes histĆ³ricos como systemd-sysv-generator, systemd-rc-local-generator y systemd-sysv-install.

Junto a esta limpieza de cĆ³digo antiguo, se han elevado significativamente los requisitos mĆ­nimos de software para el ecosistema systemd:

  • Kernel de Linux: MĆ­nimo versiĆ³n 5.10.
  • Glibc: 2.34.
  • OpenSSL: 3.0.0.
  • Util-linux: 2.37.
  • Otros: Python 3.9.0, cryptsetup 2.4.0 y libseccomp 2.4.0.

Modularidad y carga dinƔmica en libsystemd

Como parte de una iniciativa para reducir las dependencias directas en el arranque, libsystemd ahora utiliza carga dinƔmica mediante dlopen() para bibliotecas como libacl, libblkid, libseccomp, libselinux y libmount. Esto significa que el sistema solo cargarƔ estas bibliotecas en memoria cuando sus funciones especƭficas sean requeridas por un proceso, optimizando el uso de recursos. Asimismo, se ha integrado la funcionalidad de libcap directamente en libsystemd, simplificando la cadena de dependencias.

El manejo de logs ha cambiado su configuraciĆ³n por defecto: el modo de almacenamiento del diario (Journal) pasa de Ā«automĆ”ticoĀ» a Ā«persistenteĀ», independientemente de si el directorio /var/log/journal existĆ­a previamente.

En el Ć”mbito de redes y virtualizaciĆ³n:

  • systemd-networkd y systemd-nspawn: Se elimina el soporte para reglas NAT mediante iptables, dejando a nftables como la Ćŗnica opciĆ³n compatible.
  • systemd-resolved: Ahora permite el uso de ganchos locales (hooks) en /run/systemd/resolve.hook/ para intervenir en las solicitudes de resoluciĆ³n de nombres.
  • systemd-importd: Se ha integrado la lĆ³gica para trabajar con archivos TAR de forma nativa. AdemĆ”s, tanto importd como machined ahora pueden ejecutarse a nivel de usuario, permitiendo gestionar imĆ”genes en el directorio local del usuario (~/.local/state/machines/).

Otras innovaciones

La API basada en el protocolo Varlink recibio mejoras para permitir el acceso a configuraciones de servicios y realizar llamadas IPC como Reload() y Reexecute(). Para los administradores de sistemas, la inclusiĆ³n de la propiedad OOMKills en los servicios serĆ” de gran utilidad, ya que permitirĆ” rastrear cuĆ”ntas veces un proceso fue finalizado por falta de memoria directamente desde las herramientas de systemd.

Finalmente, el arranque del sistema se vuelve mĆ”s moderno con la eliminaciĆ³n del soporte para TPM 1.2 en systemd-boot, centrando todos los esfuerzos de seguridad en el estĆ”ndar TPM 2.0.

Si estƔs interesado en poder conocer mƔs al respecto, puedes consultar los detalles en el siguiente enlace.


Add as preferred source