Thorsten Kukuk, udhëheqës i grupit të zhvillimit të teknologjisë së ardhshme në SUSE (Ekipi i Teknologjisë së Ardhshme, zhvillon openSUSE MicroOS dhe SLE Micro), i cili më parë drejtoi projektin SUSE LINUX Enterprise Server për 10 vjet, sugjeroi heqjen e skedarit /var/run/utmp në shpërndarjet për të adresuar plotësisht problemin e vitit 2038 në Glibc. Të gjitha aplikacionet që përdorin utmp, wtmp dhe lastlog janë propozuar të konvertohen në marrjen e një liste përdoruesish që përdorin systemd-logind.
Më 19 janar 2038, numëruesit e kohës epokale të specifikuara nga lloji 32-bit time_t do të vërshojnë. Glibc, pavarësisht se prezantoi një tip time_t 64-bit, vazhdon të përdorë një tip time_t 32-bit në disa raste në platformat 64-bit për të ruajtur përputhshmërinë me aplikacionet e hapësirës së përdoruesit 32-bit. Një rast i tillë është skedari /var/run/utmp, i cili ruan të dhëna për përdoruesit e regjistruar aktualisht në sistem. Fusha e kohës në utmp specifikohet duke përdorur një vlerë 32-bit time_t.
Thjesht zëvendësimi i fushës së kohës në utmp nga një lloj 32-bit në një tip 64-bit nuk do të funksionojë, pasi kjo do të çojë në një ndryshim në Glibc ABI (lloji do të ndryshojë në funksione si login(), getutid() dhe utmpname ()) dhe prishja e pajtueshmërisë me aplikacionet që përdorin utmp, duke përfshirë w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, menaxherët e ekranit xterm, emacs, openssh, qemu, samba, rsyslog, etj. Për shkak të bollëkut të kurtheve të mundshme dhe kompleksitetit, ideja e zëvendësimit të tipit time_t në utmp u refuzua nga zhvilluesit e Glibc. Për të njëjtën arsye, opsioni i përdorimit të hapësirës së lirë të disponueshme në strukturën utmp për të shtuar një fushë shtesë kohore 64-bit u hodh poshtë.
Për më tepër, ndryshimi i thellësisë së bitit të tipit në utmp nuk zgjidh problemet e tjera ekzistuese, të cilat unë gjithashtu do të doja të heqja qafe. Për shembull, shkrimi në utmp kërkon të drejta të veçanta, gjë që kërkon që proceseve t'u jepen privilegje shtesë. Një problem tjetër është se arkitektura utmp lejon përdoruesit lokalë të kryejnë sulme DoS, duke çuar në ndërprerjen e shërbimit utmp përmes manipulimit të bllokimeve të skedarëve, gjë që e bën të pamundur të jesh i sigurt se përmbajtja e utmp pasqyron gjendjen reale në sistem. U propozua të përdorej një proces shtesë sfondi për të trajtuar aksesin në utmp, por për detyra të tilla tashmë ekziston një proces systemd-logind dhe nisja e një procesi tjetër të specializuar nuk këshillohet (aplikacionet do të duhet të transferojnë të dhëna në dy trajtues njëkohësisht).
Në të njëjtën kohë, edhe kur zgjidhet problemi me sulmet DoS, përmbajtja e utmp mbetet vetëm informuese dhe nuk garanton një pasqyrim të realitetit. Për shembull, emulatorë të ndryshëm dhe multipleksues të terminaleve pasqyrojnë gjendjen e tyre ndryshe - lëshimi i pesë terminaleve GNOME do të rezultojë që një përdorues të pasqyrohet në utmp dhe lëshimi i pesë terminaleve konsole ose xterm në KDE do të rezultojë në gjashtë. Sjellja e ekranit dhe tmux është njësoj e ndryshme: në rastin e parë, çdo seancë llogaritet si një përdorues i veçantë, dhe në të dytin, vetëm një përdorues pasqyrohet për të gjitha seancat.
Si rezultat, si zgjidhja më e thjeshtë, propozohet transferimi i të gjitha aplikacioneve për të përdorur shërbimin alternativ tashmë ekzistues systemd-logind dhe, pasi nuk ka programe aktuale që hyjnë në utmp, ndaloni regjistrimin në utmp. Për të zëvendësuar wtmp, propozohet të përgatiten ndërfaqe softuerike për të shkruar dhe lexuar informacione rreth përdoruesve që përdorin systemd-journald. Baza e kodeve për lëshimin e ardhshëm të systemd 254 tashmë përfshin funksionalitetin e nevojshëm për të ofruar të dhëna zëvendësuese utmp nëpërmjet libsystemd duke përdorur API-në sd-login.h ose nëpërmjet DBUS.
Burimi: opennet.ru