SUSE tulevikutehnoloogia meeskonna juht Thorsten Kukuk (Future Technology Team, arendab openSUSE MicroOSe ja SLE Micro), kes juhtis varem 10 aastat SUSE LINUX Enterprise Serveri projekti, soovitas vabaneda /var/run/utmp failist distributsioonid, et täielikult lahendada Y2038 probleem Glibcis. Kõik rakendused, mis kasutavad utmp-, wtmp- ja lastlog-i, soovitatakse teisaldada, et saada systemd-logindi kasutajate loend.
19. jaanuaril 2038 täituvad 32-bitise time_t tüübiga määratud ajastu ajaloendurid üle. Glibcis, hoolimata 64-bitise time_t tüübi kasutuselevõtust, kasutatakse 32-bitiste kasutajaruumi rakendustega ühilduvuse säilitamiseks teatud juhtudel 64-bitistel platvormidel 32-bitist time_t tüüpi. Üks selline juhtum on /var/run/utmp fail, mis salvestab andmeid praegu süsteemi sisse logitud kasutajate kohta. Utmp-i ajaväli määratakse 32-bitise time_t väärtusega.
Lihtsalt utmp-i välja muutmine 32-bitiselt tüübilt 64-bitiseks tüübiks aja jooksul ei toimi, kuna see muudab Glibc ABI-d (tüüp muutub sellistes funktsioonides nagu login(), getutid() ja utmpname() ) ja katkestada ühilduvus utmp-d kasutavate rakendustega, sealhulgas w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm kuvahaldurid, emacs, openssh, qemu, samba, rsyslog jne. Võimalike lõksude rohkuse ja töömahukuse tõttu lükkasid Glibc arendajad tagasi idee asendada time_t tüübi bitipikkus utmp-s. Samal põhjusel loobuti võimalusest kasutada utmp-struktuuris saadaolevat ruumi täiendava 64-bitise ajavälja lisamiseks.
Lisaks ei lahenda tüübi bitisügavuse muutmine utmp-s muid olemasolevaid probleeme, millest tahaks samuti lahti saada. Näiteks utmp-i kirjutamiseks on vaja eriõigusi, mis nõuab protsessidele täiendavate õiguste andmist. Teine probleem on see, et utmp-arhitektuur võimaldab kohalikel kasutajatel sooritada DoS-i ründeid, mis rikuvad utmp-teenuse faililukkude manipuleerimise kaudu, muutes võimatuks olla kindel, et utmp-i sisu peegeldab süsteemi tegelikku olekut. Utmp-le juurdepääsu haldamiseks tehti ettepanek kasutada täiendavat taustprotsessi, kuid selliste ülesannete jaoks on juba süsteemsesse sisselogimise protsess olemas ja teise spetsiaalse protsessi käivitamine pole soovitatav (rakendused peavad edastama andmeid korraga kahele töötlejale) .
Samal ajal jääb utmp-i sisu isegi DoS-i rünnakutega probleemi lahendamisel ainult informatiivseks, mis ei taga tegelikkuse peegeldust. Näiteks erinevad terminali emulaatorid ja multiplekserid kajastavad oma olekut erinevalt – viie GNOME terminali käivitamisel kajastub utmp-s üks kasutaja, KDE-s viie konsooli või xtermi terminali käitamine aga kuus. Samamoodi erineb ekraani ja tmuxi käitumine, esimesel juhul arvestatakse iga seanss eraldi kasutajana ja teisel kajastub kõigi seansside puhul ainult üks kasutaja.
Selle tulemusena on kõige lihtsama lahendusena tehtud ettepanek viia kõik rakendused üle juba olemasoleva alternatiivse systemd-logind-teenuse kasutamiseks ja pärast seda, kui utmp-le juurde pääsevad tegelikud programmid, lõpetada utmp-le kirjutamine. Wtmp asendamiseks tehakse ettepanek valmistada API-d ette kasutajate kohta teabe kirjutamiseks ja lugemiseks, kasutades systemd-journald. Systemd 254 järgmise väljalaske koodibaas sisaldab juba vajalikke funktsioone, et pakkuda asendus-utmp-andmeid libsystemdi kaudu, kasutades sd-login.h API või DBUS-i.
Allikas: opennet.ru