Thorsten Kukuk, líder del Equipo de tecnología futura de SUSE (Equipo de tecnología futura, desarrolla openSUSE MicroOS y SLE Micro), quien anteriormente dirigió el proyecto SUSE LINUX Enterprise Server durante 10 años, sugirió deshacerse del archivo /var/run/utmp en distribuciones para abordar completamente el problema Y2038 en Glibc. Se propone mover todas las aplicaciones que usan utmp, wtmp y lastlog para obtener una lista de usuarios que usan systemd-logind.
El 19 de enero de 2038, se desbordarán los contadores de tiempo de época especificados por el tipo time_t de 32 bits. En Glibc, a pesar de la introducción del tipo time_t de 64 bits, para mantener la compatibilidad con aplicaciones de espacio de usuario de 32 bits, el tipo time_t de 64 bits todavía se usa en algunos casos en plataformas de 32 bits. Uno de esos casos es el archivo /var/run/utmp, que almacena datos sobre los usuarios actualmente conectados al sistema. El campo de tiempo en utmp se establece utilizando un valor time_t de 32 bits.
Simplemente cambiar un campo en utmp de un tipo de 32 bits a un tipo de 64 bits con el tiempo no funcionará, ya que esto cambiará la Glibc ABI (el tipo cambiará en funciones como login(), getutid() y utmpname() ) y romper la compatibilidad con aplicaciones que usan utmp, incluidas w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm display managers, emacs, openssh, qemu, samba, rsyslog, etc. Debido a la abundancia de posibles escollos y laboriosidad, los desarrolladores de Glibc rechazaron la idea de reemplazar la longitud de bits del tipo time_t en utmp. Por la misma razón, se eliminó la opción de usar el espacio disponible en la estructura utmp para agregar un campo de tiempo adicional de 64 bits.
Además, cambiar la profundidad de bits del tipo en utmp no resuelve otros problemas existentes, de los que también me gustaría deshacerme. Por ejemplo, escribir en utmp requiere permisos especiales, lo que requiere que se otorguen privilegios adicionales a los procesos. Otro problema es que la arquitectura utmp permite a los usuarios locales realizar ataques DoS que rompen el servicio utmp mediante la manipulación de bloqueos de archivos, lo que hace imposible estar seguro de que el contenido de utmp refleje el estado real del sistema. Se propuso usar un proceso en segundo plano adicional para manejar el acceso a utmp, pero para tales tareas ya existe un proceso systemd-logind y no es recomendable iniciar otro proceso especializado (las aplicaciones tendrán que transferir datos a dos controladores al mismo tiempo) .
Al mismo tiempo, incluso al resolver el problema con los ataques DoS, el contenido de utmp sigue siendo solo informativo, sin garantizar un reflejo de la realidad. Por ejemplo, diferentes emuladores de terminales y multiplexores reflejan su estado de manera diferente: ejecutar cinco terminales GNOME dará como resultado que un usuario se refleje en utmp, mientras que ejecutar cinco terminales konsole o xterm en KDE dará como resultado seis. Del mismo modo, el comportamiento de screen y tmux difiere, en el primer caso cada sesión se cuenta como un usuario independiente y en el segundo solo se refleja un usuario para todas las sesiones.
Como resultado, como la solución más simple, se propone transferir todas las aplicaciones para usar el servicio systemd-logind alternativo ya existente y, después de que no haya programas reales que accedan a utmp, dejar de escribir en utmp. Para reemplazar wtmp, se propone preparar API para escribir y leer información sobre los usuarios que usan systemd-journald. La base de código para la próxima versión de systemd 254 ya incluye las funciones necesarias para proporcionar datos utmp de reemplazo a través de libsystemd usando la API sd-login.h o a través de DBUS.
Fuente: opennet.ru