Thorsten Kukuk, l\u00edder del equipo de desarrollo de tecnolog\u00edas futuras en SUSE (Future Technology Team, desarrolla openSUSE MicroOS y SLE Micro), quien anteriormente dirigi\u00f3 durante 10 a\u00f1os el proyecto SUSE LINUX Enterprise Server, propuso eliminar el archivo \/var\/run\/utmp en las distribuciones para resolver completamente el problema del a\u00f1o 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. <\/p>\n
El 19 de enero de 2038 se producir\u00e1 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\u00f3n 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\u00e1n actualmente trabajando en el sistema. El campo de tiempo en utmp se establece utilizando un valor time_t de 32 bits. <\/p>\n
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\u00eda un cambio en el ABI de Glibc (se modificar\u00eda el tipo en funciones como login(), getutid() y utmpname()) y romper\u00eda 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\u00f3n del tipo time_t en utmp fue descartada por los desarrolladores de Glibc. Por la misma raz\u00f3n, se desestim\u00f3 la opci\u00f3n de utilizar el espacio libre en la estructura utmp para a\u00f1adir un campo adicional de tiempo de 64 bits. <\/p>\n
Adem\u00e1s, cambiar la precisi\u00f3n del tipo en utmp no resuelve otros problemas existentes de los que tambi\u00e9n nos gustar\u00eda deshacernos. Por ejemplo, se requieren permisos especiales para escribir en utmp, lo que implica otorgar privilegios adicionales a los procesos. Otro problema est\u00e1 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\u00e9s 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\u00edan que enviar datos a dos manejadores al mismo tiempo). <\/p>\n
Sin embargo, 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: al iniciar cinco terminales GNOME, se registrar\u00e1 en utmp un solo usuario, mientras que al iniciar cinco terminales konsole o xterm en KDE, se registrar\u00e1n seis. De la misma manera, el comportamiento de screen y tmux difiere; en el primer caso, cada sesi\u00f3n se cuenta como un usuario separado, mientras que en el segundo, solo se refleja un usuario para todas las sesiones. <\/p>\n