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. <\/p>\n
Il 19 gennaio 2038 si verificher\u00e0 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\u00e0 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 \u00e8 il file \/var\/run\/utmp, che memorizza i dati sugli utenti attualmente attivi nel sistema. Il campo del tempo in utmp \u00e8 impostato utilizzando un valore time_t a 32 bit. <\/p>\n
Semplicemente sostituire il campo del tempo in utmp da 32 bit a 64 bit non \u00e8 possibile, poich\u00e9 ci\u00f2 porterebbe a una modifica dell'ABI di Glibc (cambiare il tipo nelle funzioni, come login(), getutid() e utmpname()) e a una compromissione della compatibilit\u00e0 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\u00ec via. A causa della variet\u00e0 di potenziali problemi e del lavoro necessario, l'idea di cambiare la dimensione del tipo time_t in utmp \u00e8 stata scartata dagli sviluppatori di Glibc. Per lo stesso motivo, \u00e8 stata abbandonata l'idea di utilizzare lo spazio disponibile nella struttura utmp per aggiungere un campo temporale a 64 bit. <\/p>\n
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 \u00e8 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 \u00e8 stato proposto di utilizzare un processo in background aggiuntivo, ma per tali compiti esiste gi\u00e0 il processo systemd-logind e avviare un ulteriore processo specializzato non \u00e8 pratico (le applicazioni dovrebbero trasmettere i dati simultaneamente a due elaboratori). <\/p>\n
Tuttavia, anche risolvendo il problema degli attacchi DoS, il contenuto di utmp rimane solo informativo e non garantisce una riflessione della realt\u00e0. Ad esempio, diversi emulatori e multiplexer di terminali riflettono il proprio stato in modo diverso: l'avvio di cinque terminali GNOME porter\u00e0 alla registrazione di un solo utente in utmp, mentre l'avvio di cinque terminali konsole o xterm in KDE porter\u00e0 a registrare sei utenti. Analogamente, il comportamento di screen e tmux \u00e8 diverso: nel primo caso ogni sessione viene considerata come un utente separato, mentre nel secondo viene registrato solo un utente per tutte le sessioni. <\/p>\n