Thorsten Kukuk, a SUSE jövőbeli technológiai fejlesztési csoportjának vezetője (Future Technology Team, openSUSE MicroOS-t és SLE Micro-t fejleszt), aki korábban 10 évig vezette a SUSE LINUX Enterprise Server projektet, azt javasolta, hogy szabaduljanak meg a /var/run/utmp fájltól. disztribúciókban, hogy teljes mértékben kezelje a 2038-as problémát a Glibc-ben. Az utmp, wtmp és lastlog protokollokat használó összes alkalmazást a rendszer a systemd-logind használatával a felhasználók listájának lekérésére javasolja.
19. január 2038-én a 32 bites time_t típus által meghatározott epochális időszámlálók túlcsordulnak. A Glibc annak ellenére, hogy bevezette a 64 bites time_t típust, bizonyos esetekben továbbra is 32 bites time_t típust használ a 64 bites platformokon, hogy fenntartsa a 32 bites felhasználói terület alkalmazásokkal való kompatibilitást. Az egyik ilyen eset a /var/run/utmp fájl, amely a rendszerbe jelenleg bejelentkezett felhasználók adatait tárolja. Az utmp időmezője 32 bites time_t értékkel van megadva.
Az utmp időmezőjének egyszerű cseréje 32 bitesről 64 bites típusra nem fog működni, mivel ez a Glibc ABI változásához vezet (a típus megváltozik az olyan függvényekben, mint a login(), a getutid() és az utmpname ()) és megszakítja a kompatibilitást az utmp-t használó alkalmazásokkal, beleértve a w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm display managers, emacs, openssh, qemu, samba, rsyslog stb. A rengeteg lehetséges buktató és bonyolultság miatt a Glibc fejlesztői elutasították a time_t típus utmp-ben való lecserélésének ötletét. Ugyanezen okból elvetették azt a lehetőséget, hogy az utmp-struktúra rendelkezésre álló szabad területét egy további 64 bites időmező hozzáadására használják fel.
Ráadásul a bitmélység típusának megváltoztatása az utmp-ben nem oldja meg a többi meglévő problémát, amitől szintén szeretnék megszabadulni. Például az utmp-be íráshoz speciális jogok szükségesek, amihez a folyamatoknak további jogosultságokat kell biztosítaniuk. Egy másik probléma, hogy az utmp architektúra lehetővé teszi a helyi felhasználók számára, hogy DoS támadásokat hajtsanak végre, ami az utmp szolgáltatás megszakításához vezet a fájlzárak manipulálásával, ami lehetetlenné teszi annak biztosítását, hogy az utmp tartalma a rendszer valós állapotát tükrözze. Az utmp-hez való hozzáférés kezeléséhez egy további háttérfolyamatot javasoltak, de az ilyen feladatokhoz már létezik systemd-logind folyamat, és egy másik speciális folyamat elindítása nem célszerű (az alkalmazásoknak egyszerre két kezelőhöz kell adatokat továbbítaniuk).
Ugyanakkor még a DoS támadásokkal való probléma megoldásakor is az utmp tartalma csak tájékoztató jellegű, és nem garantálja a valóság tükrözését. Például a különböző emulátorok és terminálmultiplexerek eltérően tükrözik állapotukat – öt GNOME terminál elindítása egy felhasználót eredményez az utmp-ben, öt konzol vagy xterm terminál elindítása pedig hatot eredményez a KDE-ben. Hasonlóan eltérő a képernyő és a tmux viselkedése: az első esetben minden munkamenet külön felhasználónak számít, a második esetben pedig csak egy felhasználó jelenik meg az összes munkamenetben.
Ennek eredményeként a legegyszerűbb megoldásként azt javasoljuk, hogy az összes alkalmazást a már meglévő alternatív systemd-logind szolgáltatás használatára helyezzék át, és miután nincsenek aktuális programok, amelyek hozzáférnének az utmp-hez, állítsák le az utmp-be történő rögzítést. A wtmp helyettesítésére javasolt szoftveres felületek előkészítése a felhasználókról szóló információk írására és olvasására a systemd-journald használatával. A systemd 254 következő kiadásának kódbázisa már tartalmazza az utmp-csereadatok biztosításához szükséges funkciókat a libsystemd-en keresztül az sd-login.h API-n vagy a DBUS-on keresztül.
Forrás: opennet.ru