Thorsten Kukuk, vedoucí týmu Future Technology Team v SUSE (Future Technology Team, vyvíjí openSUSE MicroOS a SLE Micro), který předtím 10 let vedl projekt SUSE LINUX Enterprise Server, navrhl zbavit se souboru /var/run/utmp v distribuce, které plně řeší problém Y2038 v Glibc. Všechny aplikace používající utmp, wtmp a lastlog jsou navrženy tak, aby byly přesunuty do získání seznamu uživatelů pomocí systemd-logind.
19. ledna 2038 přetečou čítače času epoch určené 32bitovým typem time_t. V Glibc, navzdory zavedení 64bitového typu time_t, se kvůli zachování kompatibility s 32bitovými aplikacemi v uživatelském prostoru stále v některých případech na 64bitových platformách používá 32bitový typ time_t. Jedním z takových případů je soubor /var/run/utmp, který ukládá data o uživatelích aktuálně přihlášených do systému. Časové pole v utmp se nastavuje pomocí 32bitové hodnoty time_t.
Pouhá změna pole v utmp v průběhu času z 32bitového na 64bitový typ nebude fungovat, protože to změní Glibc ABI (typ se změní ve funkcích jako login(), getutid() a utmpname()) a narušit kompatibilitu s aplikacemi, které používají utmp, včetně w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm display managery, emacs, openssh, qemu, samba, rsyslog atd. Vzhledem k množství možných úskalí a pracnosti byla myšlenka nahrazení bitové délky typu time_t v utmp zamítnuta vývojáři Glibc. Ze stejného důvodu byla vypuštěna možnost použít dostupný prostor ve struktuře utmp k přidání dalšího 64bitového časového pole.
Navíc změna bitové hloubky typu v utmp neřeší další existující problémy, kterých bych se také rád zbavil. Například zápis do utmp vyžaduje speciální oprávnění, která vyžadují udělení dalších oprávnění procesům. Dalším problémem je, že architektura utmp umožňuje místním uživatelům provádět DoS útoky, které narušují službu utmp manipulací se zámky souborů, což znemožňuje jistotu, že obsah utmp odráží skutečný stav v systému. Bylo navrženo použít další proces na pozadí pro zpracování přístupu k utmp, ale pro takové úlohy již existuje proces systemd-logind a spouštění jiného specializovaného procesu není vhodné (aplikace budou muset přenášet data dvěma obslužným rutinám současně) .
Přitom i při řešení problému s DoS útoky zůstává obsah utmp pouze informační, nezaručující odraz reality. Například různé terminálové emulátory a multiplexery odrážejí svůj stav odlišně – spuštění pěti terminálů GNOME bude mít za následek, že se jeden uživatel projeví v utmp, zatímco spuštění pěti terminálů konsole nebo xterm v KDE bude mít za následek šest. Podobně se liší chování screen a tmux, v prvním případě se každá relace počítá jako samostatný uživatel a ve druhém se pro všechny relace odráží pouze jeden uživatel.
V důsledku toho se jako nejjednodušší řešení navrhuje převést všechny aplikace do již existující alternativní služby systemd-logind a poté, co nebudou k utmp přistupovat žádné skutečné programy, přestat zapisovat do utmp. Pro nahrazení wtmp se navrhuje připravit API pro zápis a čtení informací o uživatelích pomocí systemd-journald. Kódová základna pro příští vydání systemd 254 již obsahuje nezbytné funkce pro poskytování náhradních dat utmp prostřednictvím libsystemd pomocí sd-login.h API nebo přes DBUS.
Zdroj: opennet.ru