Thorsten Kukuk, leider van het Future Technology Team bij SUSE (Future Technology Team, ontwikkelt openSUSE MicroOS en SLE Micro), die eerder 10 jaar lang het SUSE LINUX Enterprise Server-project leidde, stelde voor om het /var/run/utmp-bestand in distributies om het Y2038-probleem in Glibc volledig aan te pakken. Er wordt voorgesteld om alle toepassingen die utmp, wtmp en lastlog gebruiken te verplaatsen naar een lijst met gebruikers die systemd-logind gebruiken.
Op 19 januari 2038 zullen de epoch-tellers die zijn gedefinieerd door het 32-bits type time_t overlopen. In Glibc wordt, ondanks de introductie van het 64-bits time_t-type, om de compatibiliteit met 32-bits gebruikersruimtetoepassingen te behouden, het 64-bits time_t-type in sommige gevallen nog steeds gebruikt op 32-bits platforms. Een voorbeeld van zo'n geval is het bestand /var/run/utmp, dat gegevens opslaat over de gebruikers die momenteel op het systeem zijn ingelogd. Het tijdveld in utmp wordt ingesteld met een 32-bits time_t-waarde.
Het simpelweg veranderen van een veld in utmp van een 32-bits type naar een 64-bits type in de loop van de tijd zal niet werken, aangezien dit de Glibc ABI zal veranderen (het type zal veranderen in functies zoals login(), getutid() en utmpname() ) en verbreken de compatibiliteit met applicaties die utmp gebruiken, waaronder w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm display managers, emacs, openssh, qemu, samba, rsyslog, enz. Vanwege de overvloed aan mogelijke valkuilen en bewerkelijkheid werd het idee om de bitlengte van het type time_t in utmp te vervangen afgewezen door de ontwikkelaars van Glibc. Om dezelfde reden is de optie om de beschikbare ruimte in de utmp-structuur te gebruiken om een extra 64-bits tijdveld toe te voegen, komen te vervallen.
Daarnaast lost het wijzigen van de bitdiepte van het type in utmp geen andere bestaande problemen op, waar ik ook graag vanaf zou willen. Voor het schrijven naar utmp zijn bijvoorbeeld speciale machtigingen vereist, waardoor extra rechten aan processen moeten worden verleend. Een ander probleem is dat de utmp-architectuur lokale gebruikers in staat stelt DoS-aanvallen uit te voeren die de utmp-service onderbreken door manipulatie van bestandsvergrendelingen, waardoor het onmogelijk is om er zeker van te zijn dat de inhoud van utmp de werkelijke toestand van het systeem weergeeft. Er werd voorgesteld om een extra achtergrondproces te gebruiken om de toegang tot utmp af te handelen, maar voor dergelijke taken is er al een systemd-logind-proces en het starten van een ander gespecialiseerd proces is niet aan te raden (applicaties zullen tegelijkertijd gegevens naar twee handlers moeten overbrengen) .
Tegelijkertijd blijft de inhoud van utmp, zelfs bij het oplossen van het probleem met DoS-aanvallen, alleen informatief en garandeert geen weerspiegeling van de werkelijkheid. Bijvoorbeeld, verschillende terminalemulators en multiplexers geven hun status anders weer - het draaien van vijf GNOME-terminals zal resulteren in één gebruiker die wordt gereflecteerd in utmp, terwijl het draaien van vijf konsole- of xterm-terminals in KDE zal resulteren in zes. Evenzo verschilt het gedrag van scherm en tmux, in het eerste geval wordt elke sessie geteld als een afzonderlijke gebruiker en in het tweede geval wordt slechts één gebruiker weergegeven voor alle sessies.
Daarom wordt als eenvoudigste oplossing voorgesteld om alle applicaties over te zetten om de reeds bestaande alternatieve systemd-logind-service te gebruiken en, nadat er geen daadwerkelijke programma's zijn die toegang hebben tot utmp, te stoppen met schrijven naar utmp. Om wtmp te vervangen, wordt voorgesteld om API's voor te bereiden voor het schrijven en lezen van informatie over gebruikers die systemd-journald gebruiken. De codebase voor de volgende release van systemd 254 bevat al de nodige functies om vervangende utmp-gegevens te leveren via libsystemd met behulp van de sd-login.h API of via DBUS.
Bron: opennet.ru