Thorsten Kukuk, líder del equipo de desarrollo de tecnologías futuras en SUSE (Future Technology Team, desarrolla openSUSE MicroOS y SLE Micro), quien anteriormente dirigió durante 10 años el proyecto SUSE LINUX Enterprise Server, propuso eliminar el archivo /var/run/utmp en las distribuciones para resolver completamente el problema del año 2038 en Glibc. Se sugiere que todas las aplicaciones que utilizan utmp, wtmp y lastlog sean trasladadas a obtener la lista de usuarios mediante systemd-logind.
El 19 de enero de 2038 se producirá un desbordamiento de los contadores de tiempo epoch, definidos por el tipo time_t de 32 bits. En la biblioteca Glibc, a pesar de la implementación del tipo time_t de 64 bits, para mantener la compatibilidad con aplicaciones de 32 bits, en algunos casos se sigue utilizando el tipo time_t de 32 bits en plataformas de 64 bits. Uno de estos casos es el archivo /var/run/utmp, que almacena datos sobre los usuarios que están actualmente trabajando en el sistema. El campo de tiempo en utmp se establece utilizando un valor time_t de 32 bits.
Simplemente cambiar el campo de tiempo en utmp de un tipo de 32 bits a uno de 64 bits no es posible, ya que esto causaría un cambio en el ABI de Glibc (se modificaría el tipo en funciones como login(), getutid() y utmpname()) y rompería la compatibilidad con aplicaciones que utilizan utmp, entre las que se encuentran w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm, gestores de pantalla, emacs, openssh, qemu, samba, rsyslog, etc. Debido a la abundancia de posibles complicaciones y a la dificultad del proceso, la idea de cambiar la precisión del tipo time_t en utmp fue descartada por los desarrolladores de Glibc. Por la misma razón, se desestimó la opción de utilizar el espacio libre en la estructura utmp para añadir un campo adicional de tiempo de 64 bits.
Además, cambiar la precisión del tipo en utmp no resuelve otros problemas existentes de los que también nos gustaría deshacernos. Por ejemplo, se requieren permisos especiales para escribir en utmp, lo que implica otorgar privilegios adicionales a los procesos. Otro problema está relacionado con el hecho de que la arquitectura de utmp permite a los usuarios locales realizar ataques DoS, lo que interrumpe el funcionamiento del servicio utmp a través de manipulaciones en el bloqueo del archivo, por lo que no se puede garantizar que el contenido de utmp refleje el estado real en el sistema. Se propuso utilizar un proceso de fondo adicional para gestionar el acceso a utmp, pero ya existe el proceso systemd-logind para estas tareas, y lanzar otro proceso especializado no es factible (las aplicaciones tendrían que enviar datos a dos manejadores al mismo tiempo).
Incluso al resolver el problema de los ataques DoS, el contenido de utmp sigue siendo solo informativo, sin garantizar un reflejo de la realidad. Por ejemplo, diferentes emuladores y multiplexores de terminales reflejan su estado de manera diferente: iniciar cinco terminales GNOME resultará en un solo usuario reflejado en utmp, mientras que iniciar cinco terminales konsole o xterm en KDE mostrará seis. El comportamiento de screen y tmux también difiere; en el primer caso, cada sesión se cuenta como un usuario separado, mientras que en el segundo solo se refleja un usuario para todas las sesiones.
Como resultado, la solución más simple propuesta es migrar todas las aplicaciones al uso del servicio alternativo existente systemd-logind y, una vez que no queden programas relevantes que accedan a utmp, cesar la escritura en utmp. Para reemplazar wtmp, se sugiere preparar interfaces de software para registrar y leer información sobre usuarios mediante systemd-journald. Las funciones necesarias para proporcionar datos que reemplazan a utmp a través de libsystemd utilizando la API sd-login.h o mediante DBUS ya están incluidas en la base de código de la próxima versión de systemd 254.
Fuente: opennet.ru
