Thorsten Kukuk, leader del gruppo di sviluppo della tecnologia del futuro presso SUSE (Future Technology Team, sviluppa openSUSE MicroOS e SLE Micro), che in precedenza ha guidato il progetto SUSE LINUX Enterprise Server per 10 anni, ha suggerito di eliminare il file /var/run/utmp nelle distribuzioni per affrontare completamente il problema del 2038 in Glibc. Si propone di convertire tutte le applicazioni che utilizzano utmp, wtmp e lastlog per ottenere un elenco di utenti utilizzando systemd-logind.
Il 19 gennaio 2038, i contatori temporali epocali specificati dal tipo time_t a 32 bit andranno in overflow. Glibc, nonostante abbia introdotto un tipo time_t a 64 bit, continua a utilizzare un tipo time_t a 32 bit in alcuni casi su piattaforme a 64 bit per mantenere la compatibilità con le applicazioni dello spazio utente a 32 bit. Uno di questi casi è il file /var/run/utmp, che memorizza i dati sugli utenti attualmente connessi al sistema. Il campo temporale in utmp viene specificato utilizzando un valore time_t a 32 bit.
Sostituire semplicemente il campo ora in utmp da un tipo a 32 bit a uno a 64 bit non funzionerà, poiché ciò porterà a un cambiamento nell'ABI di Glibc (il tipo cambierà in funzioni come login(), getutid() e utmpname ()) e interruzione della compatibilità con applicazioni che utilizzano utmp, inclusi w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm display manager, emacs, openssh, qemu, samba, rsyslog, ecc. A causa dell'abbondanza di possibili insidie e della complessità, l'idea di sostituire il tipo time_t in utmp è stata respinta dagli sviluppatori di Glibc. Per lo stesso motivo è stata scartata la possibilità di utilizzare lo spazio libero disponibile nella struttura utmp per aggiungere un ulteriore campo temporale a 64 bit.
Inoltre, la modifica del tipo di profondità di bit in utmp non risolve altri problemi esistenti, di cui vorrei anche sbarazzarmi. Ad esempio, la scrittura su utmp richiede diritti speciali, che richiedono che ai processi vengano concessi privilegi aggiuntivi. Un altro problema è che l'architettura utmp consente agli utenti locali di effettuare attacchi DoS, portando all'interruzione del servizio utmp attraverso la manipolazione dei blocchi dei file, il che rende impossibile essere sicuri che il contenuto di utmp rifletta lo stato reale del sistema. È stato proposto di utilizzare un processo in background aggiuntivo per gestire l'accesso a utmp, ma per tali attività esiste già un processo systemd-logind e non è consigliabile avviare un altro processo specializzato (le applicazioni dovranno trasferire i dati a due gestori contemporaneamente).
Allo stesso tempo, anche quando si risolve il problema con gli attacchi DoS, i contenuti di utmp rimangono solo informativi e non garantiscono una rappresentazione della realtà. Ad esempio, diversi emulatori e multiplexer di terminale riflettono il loro stato in modo diverso: l'avvio di cinque terminali GNOME comporterà che un utente si rifletterà in utmp, mentre l'avvio di cinque terminali konsole o xterm in KDE risulterà in sei. Il comportamento di screen e tmux è altrettanto diverso: nel primo caso, ogni sessione viene conteggiata come un utente separato e nel secondo viene riflesso un solo utente per tutte le sessioni.
Di conseguenza, come soluzione più semplice, si propone di trasferire tutte le applicazioni per utilizzare il servizio alternativo systemd-logind già esistente e, quando non ci sono più programmi correnti che accedono a utmp, interrompere la registrazione su utmp. Per sostituire wtmp, si propone di preparare interfacce software per scrivere e leggere informazioni sugli utenti utilizzando systemd-journald. La base di codice per la prossima versione di systemd 254 include già le funzionalità necessarie per fornire dati di sostituzione utmp tramite libsystemd utilizzando l'API sd-login.h o tramite DBUS.
Fonte: opennet.ru