Y cuando dice “init”, obviamente se refiere al estándar actual, al amado/odiado systemd. Un sistema de inicio con el que Linus ha mantenido siempre una cierta neutralidad, más allá de algunos enfrentamientos puntuales. ¿Intensos? puede, pero sin llegar al mítico “Mauro, SHUT THE FUCK UP!”.

Parecía un mensaje cualquiera en las listas del kernel. Kees Cook de Pixel Security ponía en consideración un parche para endurecer la seguridad alrededor de SetUit (Set User ID), un medio que nos sirve para transferir los derechos de usuario, respecto a un archivo o directorio. Se trataría de establecer unos límites de memoria predeterminados en su ejecución, heredando dicha función y valores del sistema de inicio.

La respuesta de Linus, llena de consideraciones técnicas y arcanas aproximaciones al problema –para los que nos estamos metidos en el desarrollo del kernel– , también nos dejaba esta joya al final:

Veo muchos enfoques diferentes (que podrían combinarse…) y absolutamente ninguno de ellos involucra el aleatorio “tomar algunos valores de init”

Y si, una gran parte de esto es que siento que ya no puedo confiar en “init” para hacer lo sensato. Todos vosotros presumiblemente sabéis porque.

Pues no! No sabemos exactamente el motivo. ¿Será por la cada vez mayor complejidad de systemd?, que devora partes del sistema como si no hubiera un mañana o como mínimo las hacen depender del sistema de inicio. Ojalá Lennart Poettering diciendo algo así, ya sabéis for the Lulz:

I’d just like to interject for a moment. What you’re referring to as Linux, is in fact, Systemd/Linux, or as I’ve recently taken to calling it, Systemd plus Linux.

Quizás la mala fama de Lennart respecto a aceptar bugs, en especial si son CVE’s que implican temas de seguridad. Recientemente hubo un bug “no bug” bastante interesante. Al crear un nombre de usuario inválido –empezaba por un número, por ej “7day”– y lanzar un servicio del sistema con el, systemd lo detectaba como tal, pero en vez de detener su ejecución esta pasaba a correr con permisos de root.

Ahí que decir que el problema no se daba en todas las distros (en RHEL/CentOS principalmente), tenía un alcance limitado y concernía también a otras herramientas (shadow-utils) que permiten la creación de usuarios (probad a hacer un useradd -m 7day en Arch Linux, veréis como no os deja. Sin embargo ese no es el caso de RHEL/CentOS 7.3). Aún así, el sentir general es que systemd debía hacer algo por solucionar el asunto. Lennart piensa lo contrario.

Theodore Ts’o, uno de los desarrolladores más importantes y veteranos del kernel, daba su particular interpretación del asunto en Google +:

No puedo hablar por Linux, pero la razón por la que no puedo confiar en systemd es que no creo que los mantenedores de systemd tengan “buen gusto”

Obviamente se refiere a buen gusto a la hora de programar, lo que para Ts’o significa en gran manera evitar la excesiva complejidad cuando no es necesaria.

En otro apartado también critica la dificultad a la hora de depurar problemas en systemd por falta de herramientas. Y sobre todo la –según el– poco amigable actitud de Lennart, a la hora de llevar acabo discusiones técnicas

Diablos, ni siquiera quiero presentar informes de errores, solo para obtener mensajes abusivos de Lennart. Al menos cuando Linux me ataca, es porque hice daño a los usuarios lo cual yo debería haber sabido j*didamente mejor, dados mis años de experiencia en la comunidad. Lennart solo te ataca porque estás equivocado, y el tiene razón. Por definición.

Cada uno vez el asunto de systemd de manera diferente. Y no es lo mismo estar del lado del usuario de escritorio, que ser administrador de sistemas, desarrollador o constructor de distribuciones.

En cualquier caso muchos ya sueñan con un Linus tomando el mando y construyendo un sistema de inicio el mismo. Algo que ya hizo en su momento con el sistema de control de versiones y de ahí nació Git. Por ahora simplemente parece un toque de atención.

Vía | Hacker News

Imagen | John Dalton (CC-BY-SA-2.0)