Door het probleem van het jaar 2038 zou in dat jaar een deel van de software kunnen uitvallen. Het probleem treft programma's die de op POSIX gebaseerde weergave van tijd gebruiken.
Thorsten Kukuk, teamleider van SUSE Future Technology (Future Technology Team, ontwikkelt openSUSE MicroOS en SLE Micr ), die eerder het SUSE LINUX Enterprise Server-project 10 jaar leidde, stelde voor om het /var/run/utmp-bestand te verwijderen bij uitkeringen om het probleem Y2038 in Glibc volledig aan te pakken.
Ermee er wordt voorgesteld om alle applicaties die utmp, wtmp en lastlog gebruiken te verplaatsen om een lijst met gebruikers te krijgen die systemd-logind gebruiken.
Op 19 januari 2038 lopen de timers over van bepaalde periode door het 32-bit time_t type. In Glibc wordt, ondanks de introductie van het 64-bits time_t-type, om de compatibiliteit met 32-bits gebruikersruimtetoepassingen te behouden, het 32-bits time_t-type in sommige gevallen nog steeds gebruikt op 64-bits platforms.
Er zijn twee hoofdproblemen met utmp/utmpx met glibc op bijvoorbeeld x86-64:
Er wordt een 32-bits time_t-veld gebruikt voor de tijd, die in 2038 zal overlopen
Er zijn ontwerpproblemen die een DoS-aanval mogelijk maken (utmp/wtmp-blokkering stelt een onbevoegde gebruiker in staat om service te weigeren)
Een analyse van het tweede probleem door de glibc-ontwikkelaars toonde aan dat er een extra daemon nodig zou zijn om utmp/utmpx-toegang af te handelen.Hoewel er nog meer problemen zijn...
Een voorbeeld hiervan is het bestand /var/run/utmp, waarin gegevens worden opgeslagen over de gebruikers die momenteel op het systeem zijn aangesloten. Het tijdveld in utmp wordt ingesteld met een 32-bits time_t-waarde.
Er wordt vermeld dat, simpelweg een veld in utmp in de loop van de tijd veranderen van een 32-bits type naar een 64-bits type zal niet werken, omdat dit de Glibc ABI verandert (het type verandert in functies zoals login(), getutid() en utmpname()) en verbreekt de compatibiliteit met applicaties die utmp gebruiken, inclusief w, who, uptime, login, su, sudo, useradd , systemd, sysvinit, tcsh, xterm display managers, emacs, openssh, qemu, samba, rsyslog, enz.
Vanwege de overvloed aan potentiële valkuilen en bedrijvigheid, de ontwikkelaars van Glibc verwierp het idee om de bitlengte van het type time_t in utmp te vervangen. Om dezelfde reden is de optie verwijderd om de beschikbare ruimte in de utmp-structuur te gebruiken om een extra 64-bits tijdveld toe te voegen.
Ook lost het wijzigen van de bitdiepte van het type in utmp andere bestaande problemen niet op. Voor het schrijven naar utmp zijn bijvoorbeeld speciale machtigingen vereist, waardoor processen extra rechten moeten krijgen. Een ander probleem is dat de utmp-architectuur lokale gebruikers in staat stelt DoS-aanvallen uit te voeren die de utmp-service onderbreken door bestandsvergrendelingen te manipuleren, waardoor het onmogelijk is om er zeker van te zijn dat de inhoud van utmp de werkelijke status van het systeem weerspiegelt.
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 wordt niet aanbevolen om een ander gespecialiseerd proces te starten (applicaties zullen tegelijkertijd gegevens naar twee controllers moeten overbrengen).
Tegelijkertijd blijft de inhoud van utmp, zelfs door het probleem met DoS-aanvallen op te lossen, alleen informatief, zonder een weerspiegeling van de werkelijkheid te garanderen.
Verschillende terminalemulators en multiplexers geven hun toestand bijvoorbeeld anders weer: vijf GNOME-terminals draaien zal resulteren in één gebruiker die wordt gespiegeld in utmp, terwijl vijf konsole- of xterm-terminals draaien 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.
Dientengevolge, als de eenvoudigste oplossing, er wordt voorgesteld om alle applicaties over te zetten om de systemd-logind-service te gebruiken alternatief bestaat al en stop met schrijven naar utmp zodra er geen echte programma's toegang hebben tot 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.
Ten slotte is het vermeldenswaard dat de codebasis voor de volgende versie van systemd 254 bevat al de nodige functies om vervangende utmp-gegevens te leveren via libsystemd met behulp van de sd-login.ho API via DBUS.
Als u er meer over wilt weten, kunt u de details raadplegen In de volgende link.