Thorsten Kukuk, liderul echipei de dezvoltare a tehnologiilor viitoare la SUSE (Future Technology Team, care dezvoltă openSUSE MicroOS și SLE Micro), care a condus anterior timp de 10 ani proiectul SUSE LINUX Enterprise Server, a propus eliminarea fișierului /var/run/utmp din distribuții pentru a rezolva complet problema anului 2038 în Glibc. Toate aplicațiile care folosesc utmp, wtmp și lastlog sunt sugerate să fie migrate la obținerea listei utilizatorilor prin systemd-logind.
Pe 19 ianuarie 2038, va avea loc o depășire a contorilor de timp epoch setați de tipul 32-bit time_t. În biblioteca Glibc, în ciuda implementării tipului 64-bit time_t, pentru a menține compatibilitatea cu aplicațiile de 32-bit, în anumite cazuri, pe platformele de 64-bit, se continuă utilizarea tipului 32-bit time_t. Un astfel de caz este fișierul /var/run/utmp, care stochează date despre utilizatorii care sunt în prezent conectați la sistem. Câmpul de timp în utmp este setat folosind o valoare time_t de 32 de biți.
Pur și simplu înlocuirea câmpului de timp în utmp de la tipul de 32 de biți la cel de 64 de biți nu va fi posibilă, deoarece aceasta va conduce la modificarea ABI Glibc (se va schimba tipul în funcții precum login(), getutid() și utmpname()) și va duce la incompatibilități cu aplicațiile care folosesc utmp, inclusiv w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, managerii de display xterm, emacs, openssh, qemu, samba, rsyslog și altele. Din cauza abundenței de capcane posibile și a complexității, ideea de a schimba tipul time_t în utmp a fost respinsă de dezvoltatorii Glibc. Din aceleași motive, a fost abandonată și opțiunea de a utiliza spațiul liber existent în structura utmp pentru a adăuga un câmp suplimentar de 64 de biți pentru timp.
În plus, modificarea dimensiunii tipului în utmp nu rezolvă alte probleme existente de care ne-am dori să scăpăm. De exemplu, pentru a scrie în utmp sunt necesare privilegii speciale, ceea ce necesită acordarea de privilegii suplimentare proceselor. O altă problemă este legată de arhitectura utmp, care permite utilizatorilor locali să efectueze atacuri DoS, afectând funcționarea serviciului utmp prin manipularea blocărilor de fișiere, astfel încât nu poate fi garantat că conținutul utmp reflectă starea reală a sistemului. S-a propus utilizarea unui proces de fundal suplimentar pentru a gestiona accesul la utmp, dar pentru astfel de sarcini există deja procesul systemd-logind și lansarea unui alt proces specializat nu este rațională (aplicațiile vor trebui să transmită date simultan la doi procesatori).
Chiar și atunci când problema atacurilor DoS este rezolvată, conținutul utmp rămâne doar informativ, fără a garanta reflectarea realității. De exemplu, diferite emulatoare și multiplexoare de terminale își reflactă starea diferit — deschiderea a cinci terminale GNOME va duce la reflectarea unui singur utilizator în utmp, în timp ce deschiderea a cinci terminale konsole sau xterm în KDE va rezulta în șase utilizatori. Comportamentul screen și tmux este de asemenea diferit, în primul caz fiecare sesiune este contabilizată ca un utilizator separat, iar în al doilea se reflectă doar un utilizator pentru toate sesiunile.
În concluzie, ca cea mai simplă soluție, se propune trecerea tuturor aplicațiilor la utilizarea deja existentului serviciu alternativ systemd-logind și, după ce nu vor mai exista programe relevante care accesează utmp, să se oprească înregistrarea în utmp. Pentru a înlocui wtmp, se propune pregătirea interfețelor de programare pentru înregistrarea și citirea informațiilor despre utilizatori prin intermediul systemd-journald. Funcțiile necesare pentru a oferi datele de înlocuire utmp prin libsystemd folosind API-ul sd-login.h sau prin DBUS sunt deja incluse în baza de cod a următoarei versiuni systemd 254.
Sursa: opennet.ro
