El problema de l'any 2038 podria causar que una part del programari falli aquest any. El problema afecta els programes que utilitzen la representació del temps basada en el sistema POSIX
Thorsten Kukuk, líder de l'Equip de Future Technology de SUSE (Equip de tecnologia futura, desenvolupa openSUSE MicroOS i SLE Micr), qui anteriorment va dirigir el projecte SUSE LINUX Enterprise Server durant 10 anys, va suggerir desfer-se del fitxer /var/run/utmp en distribucions per abordar completament el problema Y2038 a Glibc.
Amb això es proposa moure totes les aplicacions que usen utmp, wtmp i lastlog per obtenir una llista d'usuaris que utilitzen systemd-logind.
El 19 de gener del 2038, es desbordaran els comptadors de temps d'època especificats pel tipus time_t de 32 bits. A Glibc, malgrat la introducció del tipus time_t de 64 bits, per mantenir la compatibilitat amb aplicacions d'espai d'usuari de 32 bits, el tipus time_t de 32 bits encara es fa servir en alguns casos en plataformes de 64 bits.
Hi ha dos problemes principals amb utmp/utmpx amb glibc a, per exemple, x86-64:
S'utilitza un camp time_t de 32 bits per a l'hora, que es desbordarà el 2038
Hi ha problemes de disseny que permeten un atac DoS (el bloqueig de utmp/wtmp permet que un usuari sense privilegis negui el servei)
Una anàlisi del segon problema per part dels desenvolupadors de glibc va mostrar que caldria un dimoni addicional que manegi l'accés utmp/utmpx.Tot i que hi ha alguns problemes més…
Un d'aquests casos és el fitxer /var/run/utmp, que emmagatzema dades sobre els usuaris actualment connectats al sistema. El camp de temps a utmp s'estableix mitjançant un valor time_t de 32 bits.
S'esmenta que, simplement canviar un camp en utmp amb el temps dun tipus de 32 bits a un de 64 bits no funcionarà, ja que això canviarà la Glibc ABI (el tipus canviarà en funcions com login(), getutid() i utmpname()) i trenqui la compatibilitat amb aplicacions que usen utmp, incloses 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 esculls i laboriositat, els desenvolupadors de Glibc van rebutjar la idea de reemplaçar la longitud de bits del tipus time_t a utmp. Per la mateixa raó, es va eliminar l'opció de fer servir 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, per exemple, escriure a utmp requereix permisos especials, cosa que requereix que s'atorguin privilegis addicionals als processos. Un altre problema és que l'arquitectura utmp permet als usuaris locals fer atacs DoS que trenquen el servei utmp mitjançant la manipulació de bloquejos de fitxers, cosa que fa impossible estar segur que el contingut d'utmp reflecteixi l'estat real del sistema.
Es va proposar fer servir un procés en segon pla addicional per manejar l'accés a utmp, però per a aquestes tasques ja hi ha un procés systemd-logind i no és recomanable iniciar un altre procés especialitzat (les aplicacions hauran de transferir dades a dos controladors alhora).
Alhora, fins i tot en resoldre el problema amb els atacs DoS, el contingut d'utmp segueix sent només informatiu, sense garantir un reflex de la realitat.
Per exemple, diferents emuladors de terminals i multiplexors reflecteixen el seu estat de manera diferent: executar cinc terminals GNOME donarà com a resultat que un usuari es reflecteixi en utmp, mentre que executar cinc terminals konsole o xterm al KDE donarà com a resultat sis. De la mateixa manera, el comportament de screen i tmux difereix, en el primer cas cada sessió es compta com a usuari independent i en el segon només es reflecteix un usuari per a totes les sessions.
Com a resultat, com la solució més simple, es proposa transferir totes les aplicacions per utilitzar el servei systemd-logind alternatiu ja existent i, després que no hi hagi programes reals que accedeixin a utmp, deixar d'escriure a utmp. Per reemplaçar wtmp, es proposa preparar API per escriure i llegir informació sobre els usuaris que usen systemd-journald.
Finalment, cal esmentar que la base de codi per a la propera versió de systemd 254 ja inclou les funcions necessàries per proporcionar dades utmp de reemplaçament a través de libsystemd usant l'API sd-login.ho a través del DBUS.
Si estàs interessat a poder conèixer-ne més, pots consultar els detalls en el següent enllaç.