Thorsten Kukuk, a SUSE Future Technology Team vezetője, aki korábban 10 éven át irányította a SUSE LINUX Enterprise Server projektet, javasolta, hogy a disztribúciókban hagyják el a /var/run/utmp fájlt a Glibc 2038-as probléma teljes megoldása érdekében. Minden olyan alkalmazást, amely utmp, wtmp és lastlog-t használ, áttérni javasolt a felhasználók listájának megszerzésére a systemd-logind segítségével.
2038. január 19-én a 32 bites time_t típus által definiált epoch időszámlálók túlcsordulnak. A Glibc könyvtárban, a 64 bites time_t típus bevezetése ellenére, a 32 bites alkalmazásokkal való kompatibilitás megőrzése érdekében a felhasználói térben bizonyos esetekben a 64 bites platformokon továbbra is a 32 bites time_t típust alkalmazzák. Az egyik ilyen eset a /var/run/utmp fájl, amely a rendszerben jelenleg futó felhasználók adatait tárolja. Az utmp időmezője 32 bites time_t érték felhasználásával van meghatározva.
Az utmp időmező 32 bites típusról 64 bites típusra való egyszerű cseréje nem lehetséges, mivel ez a Glibc ABI-jának megváltozását okozza (a típus megváltozik a login(), getutid() és utmpname() funkciókban), és megsérti a utmp-t használó alkalmazások, például a w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm display menedzserek, emacs, openssh, qemu, samba, rsyslog stb. kompatibilitását. A lehetséges buktatók bősége és a nehézkesség miatt a Glibc fejlesztői elvetették a time_t típus átváltásának ötletét az utmp-ban. Ugyanazon okból elvetették azt a lehetőséget is, hogy a utmp struktúrájában lévő szabad helyet egy további 64 bites időmező hozzáadására használják.
Ezenkívül a utmp típusának bitméretének megváltoztatása nem oldja meg a fennálló egyéb problémákat, amelyektől szintén meg szeretnénk szabadulni. Például a utmp-be való íráshoz speciális jogosultságokra van szükség, ami további privilégiumokat követel meg a folyamatoktól. Egy másik probléma az, hogy a utmp architektúrája lehetővé teszi, hogy a helyi felhasználók DoS-támadásokat végezzenek, amelyek megzavarják a utmp szolgáltatás működését a fájlok lockolásának manipulálásával, így nem lehetünk biztosak abban, hogy a utmp tartalma a rendszer valós állapotát tükrözi. A utmp-hez való hozzáférés kezelésére javasoltak egy háttérfolyamat használatát, de ilyen feladatokra már létezik a systemd-logind folyamat, és egy újabb speciális folyamat indítása nem indokolt (az alkalmazásoknak párhuzamosan két feldolgozóba kell adatokat átadniuk).
Még a DoS-támadások problémájának megoldása esetén is a utmp tartalma csupán tájékoztató jellegű marad, nem garantálva a valóság tükrözését. Például a különböző emulátorok és terminál multiplexerek eltérően tükrözik állapotukat - öt GNOME terminál indítása egy felhasználó tükrözéséhez vezet, míg öt konsole vagy xterm terminál indítása a KDE környezetben hat felhasználót tükröz. Hasonlóan eltér a screen és a tmux viselkedése, az előbbi esetében minden session külön felhasználónak számít, míg az utóbbi esetében csak egy felhasználó tükröződik az összes sessionon.
Végül, mint a legegyszerűbb megoldás, javasolják, hogy minden alkalmazást átállítsanak a már létező alternatív systemd-logind szolgáltatás használatára, és miután már nem marad releváns program, amelyik a utmp-hez fordul, a utmp-be való írást leállítani. A wtmp helyettesítésére programozási interfészeket javasoltak az információk felhasználók általi írására és olvasására a systemd-journald segítségével. A systemd 254 következő kiadásának kódalapjába már belekerültek a szükséges funkciók, hogy a utmp adatait a libsystemd-n keresztül biztosítsák az sd-login.h API használatával vagy a DBUS-on keresztül.
Forrás: opennet.ru
