Thorsten Kukuk, liderul viitorului grup de dezvoltare tehnologică la SUSE (Echipa de tehnologie viitoare, dezvoltă openSUSE MicroOS și SLE Micro), care a condus anterior proiectul SUSE LINUX Enterprise Server timp de 10 ani, a sugerat să scape de fișierul /var/run/utmp în distribuții pentru a aborda pe deplin problema 2038 din Glibc. Toate aplicațiile care folosesc utmp, wtmp și lastlog sunt propuse pentru a fi convertite pentru a obține o listă de utilizatori folosind systemd-logind.
Pe 19 ianuarie 2038, contoarele de timp epocale specificate de tipul time_t pe 32 de biți vor depăși. Glibc, în ciuda introducerii unui tip time_t pe 64 de biți, continuă să folosească un tip time_t pe 32 de biți în unele cazuri pe platforme pe 64 de biți pentru a menține compatibilitatea cu aplicațiile pentru spațiul utilizatorului pe 32 de biți. Un astfel de caz este fișierul /var/run/utmp, care stochează date despre utilizatorii conectați în prezent în sistem. Câmpul de timp din utmp este specificat folosind o valoare time_t de 32 de biți.
Pur și simplu înlocuirea câmpului de timp în utmp de la un tip de 32 de biți la unul de 64 de biți nu va funcționa, deoarece aceasta va duce la o schimbare în Glibc ABI (tipul se va schimba în funcții precum login(), getutid() și utmpname ()) și întreruperea compatibilității cu aplicațiile care folosesc utmp, inclusiv w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm display managers, emacs, openssh, qemu, samba, rsyslog etc. Datorită abundenței de posibile capcane și complexitate, ideea de a înlocui tipul time_t în utmp a fost respinsă de dezvoltatorii Glibc. Din același motiv, opțiunea de a utiliza spațiul liber disponibil în structura utmp pentru a adăuga un câmp de timp suplimentar de 64 de biți a fost renunțată.
În plus, schimbarea adâncimii de biți a tipului în utmp nu rezolvă alte probleme existente, de care aș dori și eu să scap. De exemplu, scrierea în utmp necesită permisiuni speciale, ceea ce necesită ca proceselor să li se acorde privilegii suplimentare. O altă problemă este că arhitectura utmp permite utilizatorilor locali să efectueze atacuri DoS, ceea ce duce la întreruperea serviciului utmp prin manipularea blocărilor de fișiere, ceea ce face imposibilă asigurarea faptului că conținutul utmp reflectă starea reală din sistem. S-a propus folosirea unui proces suplimentar de fundal pentru a gestiona accesul la utmp, dar pentru astfel de sarcini există deja un proces systemd-logind și lansarea unui alt proces specializat nu este recomandabilă (aplicațiile vor trebui să transfere date la doi handlere simultan).
În același timp, chiar și atunci când se rezolvă problema cu atacurile DoS, conținutul utmp rămâne doar informațional și nu garantează o reflectare a realității. De exemplu, diferiți emulatori și multiplexoare de terminale își reflectă starea diferit - lansarea a cinci terminale GNOME va avea ca rezultat reflectarea unui utilizator în utmp, iar lansarea a cinci terminale konsole sau xterm în KDE va avea ca rezultat șase. Comportamentul screen și tmux este la fel de diferit: în primul caz, fiecare sesiune este socotită ca un utilizator separat, iar în al doilea, un singur utilizator este reflectat pentru toate sesiunile.
Ca urmare, ca cea mai simplă soluție, se propune transferul tuturor aplicațiilor pentru a utiliza serviciul alternativ deja existent systemd-logind și, după ce nu există programe curente care accesează utmp, opriți înregistrarea în utmp. Pentru a înlocui wtmp, se propune pregătirea interfețelor software pentru scrierea și citirea informațiilor despre utilizatori folosind systemd-journald. Baza de cod pentru următoarea ediție a systemd 254 include deja funcționalitatea necesară pentru a furniza date de înlocuire utmp prin libsystemd folosind API-ul sd-login.h sau prin DBUS.
Sursa: opennet.ru
