Thorsten Kukuk, líder del Future Technology Team de SUSE (Future Technology Team, desenvolupa openSUSE MicroOS i SLE Micro), que abans va dirigir el projecte SUSE LINUX Enterprise Server durant 10 anys, va suggerir desfer-se del fitxer /var/run/utmp a distribucions per abordar completament el problema Y2038 a Glibc. Es proposa que totes les aplicacions que utilitzen utmp, wtmp i lastlog es traslladin per obtenir una llista d'usuaris que utilitzen systemd-logind.
El 19 de gener de 2038, els comptadors de temps especificats pel tipus time_t de 32 bits es desbordaran. A Glibc, malgrat la introducció del tipus time_t de 64 bits, per mantenir la compatibilitat amb les aplicacions d'espai d'usuari de 32 bits, el tipus time_t de 64 bits encara s'utilitza en alguns casos en plataformes de 32 bits. Un d'aquests casos és el fitxer /var/run/utmp, que emmagatzema dades sobre els usuaris connectats actualment al sistema. El camp de temps a utmp s'estableix mitjançant un valor time_t de 32 bits.
Simplement canviar un camp a utmp d'un tipus de 32 bits a un de 64 bits al llarg del temps no funcionarà, ja que això canviarà l'ABI de Glibc (el tipus canviarà en funcions com login(), getutid() i utmpname() ) i trencar la compatibilitat amb aplicacions que utilitzen utmp, incloent w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm display managers, emacs, openssh, qemu, samba, rsyslog, etc. A causa de l'abundància de possibles inconvenients i laboriositat, els desenvolupadors de Glibc van rebutjar la idea de substituir la longitud de bits del tipus time_t a utmp. Per la mateixa raó, es va eliminar l'opció d'utilitzar l'espai disponible a l'estructura utmp per afegir un camp de temps addicional de 64 bits.
A més, canviar la profunditat de bits del tipus a utmp no resol altres problemes existents, dels quals també m'agradaria desfer-me. Per exemple, escriure a utmp requereix permisos especials, que requereixen privilegis addicionals atorgats als processos. Un altre problema és que l'arquitectura utmp permet als usuaris locals realitzar atacs DoS que trenquen el servei utmp mitjançant la manipulació de bloquejos de fitxers, cosa que fa impossible assegurar-se que el contingut d'utmp reflecteix l'estat real del sistema. Es va proposar utilitzar un procés de fons addicional per gestionar l'accés a utmp, però per a aquestes tasques ja hi ha un procés systemd-logind i no és aconsellable iniciar un altre procés especialitzat (les aplicacions hauran de transferir dades a dos controladors alhora). .
Al mateix temps, fins i tot quan es resol el problema amb els atacs DoS, el contingut d'utmp segueix sent només informatiu, no garanteix un reflex de la realitat. Per exemple, els diferents emuladors i multiplexadors de terminal reflecteixen el seu estat de manera diferent: l'execució de cinc terminals GNOME farà que un usuari es reflecteixi a utmp, mentre que l'execució de cinc terminals konsole o xterm a KDE en donarà sis. De la mateixa manera, el comportament de pantalla i tmux difereix, en el primer cas cada sessió es compta com un usuari independent, i en el segon només es reflecteix un usuari per a totes les sessions.
Com a resultat, com a solució més senzilla, es proposa transferir totes les aplicacions per utilitzar el servei alternatiu systemd-logind ja existent i, després que no hi hagi programes reals que accedeixin a utmp, deixar d'escriure a utmp. Per substituir wtmp, es proposa preparar API per escriure i llegir informació sobre usuaris mitjançant systemd-journald. La base de codi per a la propera versió de systemd 254 ja inclou les funcions necessàries per proporcionar dades utmp de substitució mitjançant libsystemd mitjançant l'API sd-login.h o mitjançant DBUS.
Font: opennet.ru