Thorsten Kukuk, capu di u Future Technology Team in SUSE (Future Technology Team, sviluppa openSUSE MicroOS è SLE Micro), chì prima guidava u prughjettu SUSE LINUX Enterprise Server per 10 anni, hà suggeritu di sbarazzarsi di u file /var/run/utmp in distribuzioni per affruntà cumplettamente u prublema Y2038 in Glibc. Tutte l'applicazioni chì utilizanu utmp, wtmp è lastlog sò pruposti per esse spustati per ottene una lista di l'utilizatori chì utilizanu systemd-logind.
U 19 di ghjennaghju di u 2038, i contatori di u tempu di l'epica specificati da u tippu time_t 32-bit overflow. In Glibc, malgradu l'intruduzioni di u tippu time_t 64-bit, per mantene a cumpatibilità cù l'applicazioni di u spaziu di l'utilizatori 32-bit, u tipu time_t 64-bit hè sempre usatu in certi casi nantu à e plataforme 32-bit. Un tali casu hè u schedariu /var/run/utmp, chì guarda dati nantu à l'utilizatori attualmente cunnessi in u sistema. U campu di u tempu in utmp hè stabilitu cù un valore time_t di 32 bit.
Simply canging a field in utmp over time from a 32-bit to a 64-bit type ùn funziona micca, postu chì questu cambierà l'ABI di Glibc (u tipu cambierà in funzioni cum'è login (), getutid () è utmpname ()) è rompe a cumpatibilità cù l'applicazioni chì utilizanu utmp, cumprese w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm display managers, emacs, openssh, qemu, samba, rsyslog, etc. A causa di l'abbundanza di pussibile trappule è laboriosità, l'idea di rimpiazzà a durata di u bit di u tippu time_t in utmp hè stata rifiutata da i sviluppatori di Glibc. Per u listessu mutivu, l'opzione di utilizà u spaziu dispunibule in a struttura utmp per aghjunghje un campu di tempu 64-bit addiziale hè stata abbandunata.
Inoltre, cambià a prufundità di u tipu in utmp ùn risolve micca altri prublemi esistenti, chì mi piacerebbe ancu di sguassà. Per esempiu, scrive à utmp richiede permessi speciali, chì richiede privilegi supplementari per esse cuncessi à i prucessi. Un altru prublema hè chì l'architettura utmp permette à l'utilizatori lucali di eseguisce attacchi DoS chì rompenu u serviziu utmp attraversu a manipulazione di i chjusi di i schedari, facendu impussibile di esse sicuru chì u cuntenutu di utmp riflette u statu reale in u sistema. Hè stata pruposta d'utilizà un prucessu di fondo supplementu per trattà l'accessu à utmp, ma per tali compiti ci hè digià un prucessu systemd-login è inizià un altru prucessu specializatu ùn hè micca cunsigliatu (l'applicazioni anu da trasfirià dati à dui gestori à u stessu tempu) .
À u listessu tempu, ancu quandu si risolve u prublema cù l'attacchi DoS, u cuntenutu di utmp ferma solu informativu, ùn guarantisci micca un riflessu di a realità. Per esempiu, diversi emulatori di terminali è multiplexers riflettenu u so statu in modu diversu - l'esecuzione di cinque terminali GNOME hà da risultatu in un utilizatore chì si riflette in utmp, mentre chì eseguisce cinque terminali konsole o xterm in KDE hà da esse sei. In u listessu modu, u cumpurtamentu di u screen è tmux hè diversu, in u primu casu ogni sessione hè cuntatu cum'è un utilizatore separatu, è in u sicondu solu un utilizatore hè riflessu per tutte e sessione.
In u risultatu, cum'è a suluzione più simplice, hè prupostu di trasfirià tutte l'applicazioni per utilizà u serviziu alternativu systemd-logind già esistente è, dopu chì ùn ci sò micca prugrammi attuali chì accede à utmp, cessate di scrive à utmp. Per rimpiazzà wtmp, hè prupostu di preparà API per scrive è leghje infurmazioni nantu à l'utilizatori chì utilizanu systemd-journald. A basa di codice per a prossima versione di systemd 254 include digià e funzioni necessarie per furnisce dati utmp di sustituzione via libsystemd utilizendu l'API sd-login.h o via DBUS.
Source: opennet.ru