Thorsten Kukuk, leader of the Future Technology Team at SUSE, which develops openSUSE MicroOS and SLE Micro, and previously led the SUSE LINUX Enterprise Server project for 10 years, proposed to eliminate the file /var/run/utmp from distributions to fully address the 2038 issue in Glibc. It is suggested that all applications using utmp, wtmp, and lastlog transition to obtaining the user list through systemd-logind.
On January 19, 2038, the epoch time counters set by the 32-bit type time_t will overflow. In the Glibc library, despite the introduction of the 64-bit type time_t, a 32-bit type time_t continues to be used in some cases on 64-bit platforms for compatibility with 32-bit applications. One such case is the file /var/run/utmp, which stores data about users currently working in the system. The time field in utmp is set using a 32-bit time_t value.
Non è possibile semplicemente sostituire il campo del tempo in utmp da un tipo a 32 bit a uno a 64 bit, poiché ciò comporterebbe una modifica dell'ABI di Glibc (il tipo nelle funzioni come login(), getutid() e utmpname() cambierebbe) e comprometterebbe la compatibilità con le applicazioni che utilizzano utmp, tra cui w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm, gestori di visualizzazione, emacs, openssh, qemu, samba, rsyslog, ecc. A causa del numero elevato di possibili insidie e della complessità, l'idea di cambiare la dimensione del tipo time_t in utmp è stata scartata dagli sviluppatori di Glibc. Per la stessa ragione, è stata scartata l'opzione di utilizzare lo spazio libero esistente nella struttura utmp per aggiungere un ulteriore campo a 64 bit per il tempo.
Inoltre, modificare la larghezza del tipo in utmp non risolve altri problemi esistenti che si vorrebbero eliminare. Ad esempio, per scrivere in utmp sono necessari diritti speciali, il che comporta la concessione di ulteriori privilegi ai processi. Un altro problema è legato al fatto che l'architettura di utmp consente agli utenti locali di effettuare attacchi DoS, che portano a un malfunzionamento del servizio utmp a causa di manipolazioni con i blocchi del file, il che rende impossibile garantire che il contenuto di utmp rifletta lo stato reale del sistema. Per gestire l'accesso a utmp si è proposto di utilizzare un ulteriore processo in background, ma per compiti simili esiste già il processo systemd-logind, e avviare un ulteriore processo specializzato non è ragionevole (le applicazioni dovrebbero inviare dati a due gestori contemporaneamente).
Anche risolvendo il problema degli attacchi DoS, il contenuto di utmp rimane solo informativo, senza garantire una riflessione della realtà. Ad esempio, diversi emulatori e multiplexer di terminale mostrano il loro stato in modo differente: l'avvio di cinque terminali GNOME porterà a una registrazione in utmp di un solo utente, mentre l'avvio di cinque terminali konsole o xterm in KDE registrerà sei. Analogamente, il comportamento di screen e tmux è diverso; nel primo caso, ogni sessione è considerata come un utente separato, mentre nel secondo viene registrato solo un utente per tutte le sessioni.
Di conseguenza, come soluzione più semplice si propone di trasferire tutte le applicazioni all'uso del già esistente servizio alternativo systemd-logind e, una volta che non ci saranno più programmi attivi che fanno riferimento a utmp, di interrompere la registrazione in utmp. Per sostituire wtmp, si propone di preparare interfacce di programmazione per la registrazione e lettura delle informazioni sugli utenti tramite systemd-journald. Nella base di codice della prossima versione di systemd 254 sono già incluse le funzioni necessarie per fornire dati sostitutivi di utmp tramite libsystemd utilizzando l'API sd-login.h o tramite DBUS.
Fonte: opennet.ru
