Thorsten Kukuk, vedúci skupiny vývoja technológií budúcnosti v SUSE (Future Technology Team, vyvíja openSUSE MicroOS a SLE Micro), ktorý predtým 10 rokov viedol projekt SUSE LINUX Enterprise Server, navrhol zbaviť sa súboru /var/run/utmp v distribúciách na úplné vyriešenie problému 2038 v Glibc. Všetky aplikácie používajúce utmp, wtmp a lastlog sú navrhnuté tak, aby sa skonvertovali na získanie zoznamu používateľov pomocou systemd-logind.
19. januára 2038 pretečú počítadlá epochálneho času špecifikované 32-bitovým typom time_t. Glibc, napriek zavedeniu 64-bitového typu time_t, v niektorých prípadoch na 32-bitových platformách naďalej používa 64-bitový typ time_t, aby bola zachovaná kompatibilita s 32-bitovými aplikáciami v užívateľskom priestore. Jedným z takýchto prípadov je súbor /var/run/utmp, ktorý ukladá údaje o užívateľoch aktuálne prihlásených do systému. Časové pole v utmp je špecifikované pomocou 32-bitovej hodnoty time_t.
Jednoduché nahradenie časového poľa v utmp z 32-bitového na 64-bitový typ nebude fungovať, pretože to povedie k zmene Glibc ABI (typ sa zmení vo funkciách ako login(), getutid() a utmpname ()) a narušenie kompatibility s aplikáciami, ktoré používajú utmp, vrátane w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm display manager, emacs, openssh, qemu, samba, rsyslog atď. Kvôli množstvu možných úskalí a zložitosti bola myšlienka nahradenia typu time_t v utmp vývojármi Glibc odmietnutá. Z rovnakého dôvodu bola zavrhnutá možnosť využiť dostupné voľné miesto v štruktúre utmp na pridanie ďalšieho 64-bitového časového poľa.
Okrem toho zmena bitovej hĺbky typu v utmp nerieši ďalšie existujúce problémy, ktorých by som sa tiež rád zbavil. Napríklad zápis do utmp vyžaduje špeciálne práva, ktoré vyžadujú, aby boli procesom udelené ďalšie privilégiá. Ďalším problémom je, že architektúra utmp umožňuje lokálnym používateľom vykonávať DoS útoky, čo vedie k narušeniu služby utmp manipuláciou so zámkami súborov, čo znemožňuje istotu, že obsah utmp odráža skutočný stav v systéme. Navrhlo sa použiť ďalší proces na pozadí na spracovanie prístupu k utmp, ale pre takéto úlohy už existuje proces systemd-logind a spustenie iného špecializovaného procesu sa neodporúča (aplikácie budú musieť prenášať údaje do dvoch obslužných programov súčasne).
Zároveň aj pri riešení problému s DoS útokmi zostáva obsah utmp len informatívny a nezaručuje odraz reality. Napríklad rôzne emulátory a terminálové multiplexory odrážajú svoj stav odlišne - spustenie piatich terminálov GNOME bude mať za následok, že jeden používateľ sa prejaví v utmp a spustenie piatich terminálov konsole alebo xterm v KDE bude mať za následok šesť. Správanie screen a tmux je podobne odlišné: v prvom prípade sa každá relácia počíta ako samostatný používateľ a v druhom prípade sa pre všetky relácie zohľadní iba jeden používateľ.
V dôsledku toho sa ako najjednoduchšie riešenie navrhuje preniesť všetky aplikácie do už existujúcej alternatívnej služby systemd-logind a po tom, čo k utmp nepristupujú žiadne aktuálne programy, zastaviť nahrávanie do utmp. Ako náhradu wtmp sa navrhuje pripraviť softvérové rozhrania na zapisovanie a čítanie informácií o užívateľoch pomocou systemd-journald. Kódová základňa pre ďalšie vydanie systemd 254 už obsahuje potrebné funkcie na poskytovanie náhradných údajov utmp cez libsystemd pomocou sd-login.h API alebo cez DBUS.
Zdroj: opennet.ru