Thorsten Kukuk, leader del gruppo di sviluppo delle tecnologie future in SUSE, ha proposto di eliminare il file /var/run/utmp nelle distribuzioni per risolvere completamente il problema del 2038 in Glibc. Tutte le applicazioni che utilizzano utmp, wtmp e lastlog dovrebbero passare all'ottenimento della lista degli utenti tramite systemd-logind.
Il 19 gennaio 2038 si verificherà un overflow dei contatori del tempo epoch, definiti dal tipo time_t a 32 bit. Nella libreria Glibc, nonostante l'introduzione del tipo time_t a 64 bit, per mantenere la compatibilità con le applicazioni a 32 bit, in alcune circostanze, viene ancora utilizzato il tipo time_t a 32 bit su piattaforme a 64 bit. Un caso di questo tipo è il file /var/run/utmp, che memorizza i dati sugli utenti attualmente attivi nel sistema. Il campo del tempo in utmp è impostato utilizzando un valore time_t a 32 bit.
Semplicemente sostituire il campo del tempo in utmp da 32 bit a 64 bit non è possibile, poiché ciò porterebbe a una modifica dell'ABI di Glibc (cambiare il tipo nelle funzioni, come login(), getutid() e utmpname()) e a una compromissione della compatibilità con le applicazioni che utilizzano utmp, tra cui w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm, i gestori di visualizzazione, emacs, openssh, qemu, samba, rsyslog, e così via. A causa della varietà di potenziali problemi e del lavoro necessario, l'idea di cambiare la dimensione del tipo time_t in utmp è stata scartata dagli sviluppatori di Glibc. Per lo stesso motivo, è stata abbandonata l'idea di utilizzare lo spazio disponibile nella struttura utmp per aggiungere un campo temporale a 64 bit.
Inoltre, cambiare la dimensione del tipo in utmp non risolve altri problemi esistenti che si desidera eliminare. Ad esempio, la registrazione in utmp richiede privilegi speciali, il che implica fornire ulteriori privilegi ai processi. Un altro problema è legato al fatto che l'architettura di utmp consente agli utenti locali di effettuare attacchi DoS, compromettendo il funzionamento del servizio utmp attraverso manipolazioni sui lock file, rendendo impossibile essere certi che il contenuto di utmp rifletta lo stato reale nel sistema. Per gestire l'accesso a utmp è stato proposto di utilizzare un processo in background aggiuntivo, ma per tali compiti esiste già il processo systemd-logind e avviare un ulteriore processo specializzato non è pratico (le applicazioni dovrebbero trasmettere i dati simultaneamente a due elaboratori).
Anche se si risolvesse il problema degli attacchi DoS, il contenuto di utmp resterebbe solo informativo, senza garantire una riflessione della realtà. Ad esempio, diversi emulatori e multiplexer di terminali rappresentano il loro stato in modo diverso: 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 porterà a 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 suggerisce di migrare tutte le applicazioni all'uso del già esistente servizio alternativo systemd-logind e, una volta che non ci saranno più programmi attivi che accedono a utmp, di interrompere la registrazione in utmp. Per sostituire wtmp si propone di preparare interfacce software 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 attraverso libsystemd utilizzando l'API sd-login.h o tramite DBUS.
Fonte: opennet.ru
