Thorsten Kukuk, hoofd van de Future Technology Team bij SUSE, dat openSUSE MicroOS en SLE Micro ontwikkelt, en eerder 10 jaar het SUSE LINUX Enterprise Server project leidde, heeft voorgesteld om het bestand /var/run/utmp te verwijderen uit distributies als volledige oplossing voor het 2038-probleem in Glibc. Alle toepassingen die gebruikmaken van utmp, wtmp en lastlog zouden moeten overstappen op het verkrijgen van de gebruikerslijst via systemd-logind.
Op 19 januari 2038 zal er een overflow optreden van de epoch-tijd tellers, die zijn gedefinieerd door het 32-bits type time_t. In de Glibc-bibliotheek, ondanks de invoering van het 64-bits type time_t, wordt in sommige gevallen het 32-bits type time_t nog steeds gebruikt op 64-bits platformen om compatibiliteit met 32-bits toepassingen te waarborgen. Een van die gevallen is het bestand /var/run/utmp, dat gegevens opslaat over gebruikers die momenteel actief zijn in het systeem. Het tijdveld in utmp wordt ingesteld met behulp van een 32-bits waarde time_t.
Het is niet mogelijk om eenvoudig het tijdveld in utmp van een 32-bits naar een 64-bits type te veranderen, aangezien dit zou leiden tot een wijziging van de ABI van Glibc (het type in functies zoals login(), getutid() en utmpname() zou veranderen) en compatibiliteit met toepassingen die utmp gebruiken zou schenden, waaronder w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm displaymanagers, emacs, openssh, qemu, samba, rsyslog, enzovoort. Vanwege de vele mogelijke valkuilen en de complexiteit van de implementatie is het idee om de bitgrootte van time_t in utmp te vervangen afgewezen door de ontwikkelaars van Glibc. Om dezelfde reden werd de optie om de beschikbare ruimte in de utmp-structuur te gebruiken voor het toevoegen van een extra 64-bits tijdveld verworpen.
Bovendien lost het wijzigen van de bitdiepte van het type in utmp andere bestaande problemen niet op, waarvan we ook graag af zouden willen. Bijvoorbeeld, voor het schrijven naar utmp zijn speciale rechten vereist, wat het nodig maakt om processen aanvullende privileges te geven. Een ander probleem is dat de architectuur van utmp lokaal gebruikers in staat stelt DoS-aanvallen uit te voeren, wat kan leiden tot storing van de utmp-service door manipulaties met bestandsblokkeringen, waardoor je niet zeker kunt zijn dat de inhoud van utmp een realistische toestand van het systeem weerspiegelt. Voor toegang tot utmp werd voorgesteld om een extra achtergrondproces te gebruiken, maar voor dergelijke taken bestaat er al een proces systemd-logind en het starten van nog een gespecialiseerd proces is niet zinvol (toepassingen moeten gegevens gelijktijdig naar twee verwerkers sturen).
Zelfs bij een oplossing voor het DoS-aanvalprobleem blijft de inhoud van utmp echter slechts informatief, zonder garantie op een realistische weergave van de werkelijkheid. Bijvoorbeeld, verschillende emulators en multiplexers van terminals weerspiegelen hun toestand op verschillende manieren - het starten van vijf GNOME-terminals resulteert in de weergave van Ć©Ć©n gebruiker in utmp, terwijl het starten van vijf konsole- of xterm-terminals in KDE zes gebruikers weergeeft. Evenzo verschillen het gedrag van screen en tmux; in het eerste geval wordt elke sessie geteld als een afzonderlijke gebruiker, terwijl in de tweede alleen Ć©Ć©n gebruiker op alle sessies wordt weergegeven.
Als de eenvoudigste oplossing wordt voorgesteld om alle applicaties over te zetten naar het gebruik van de bestaande alternatieve service systemd-logind en zodra er geen actuele programma's meer zijn die gebruik maken van utmp, de opname in utmp te stoppen. Voor de vervanging van wtmp wordt voorgesteld om software-interfaces voor het schrijven en lezen van gebruikersinformatie voor te bereiden met behulp van systemd-journald. In de codebase van de volgende release systemd 254 zijn al de nodige functies opgenomen om vervangende utmp-gegevens via libsystemd te verstrekken met behulp van de API sd-login.h of via DBUS.
Bron: opennet.ru
