Thorsten Kukuk, ledare för den framtida teknikutvecklingsgruppen på SUSE (Future Technology Team, utvecklar openSUSE MicroOS och SLE Micro), som tidigare lett SUSE LINUX Enterprise Server-projektet i 10 år, föreslog att du skulle bli av med filen /var/run/utmp i distributioner för att helt ta itu med 2038-problemet i Glibc. Alla applikationer som använder utmp, wtmp och lastlog föreslås konverteras för att få en lista över användare som använder systemd-login.
Den 19 januari 2038 kommer epoktidsräknarna som specificeras av 32-bitars time_t-typen att svämma över. Trots att Glibc introducerar en 64-bitars time_t-typ, fortsätter att använda en 32-bitars time_t-typ i vissa fall på 64-bitars plattformar för att upprätthålla kompatibilitet med 32-bitars applikationer för användarutrymme. Ett sådant fall är filen /var/run/utmp, som lagrar data om användare som för närvarande är inloggade i systemet. Tidsfältet i utmp anges med ett 32-bitars time_t-värde.
Att helt enkelt byta ut tidsfältet i utmp från en 32-bitars till en 64-bitars typ kommer inte att fungera, eftersom detta kommer att leda till en förändring i Glibc ABI (typen kommer att ändras i funktioner som login(), getutid() och utmpname ()) och bryter kompatibiliteten med applikationer som använder utmp, inklusive w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm display managers, emacs, openssh, qemu, samba, rsyslog, etc. På grund av överflöd av möjliga fallgropar och komplexitet, avvisades idén om att ersätta time_t-typen i utmp av Glibc-utvecklarna. Av samma anledning förkastades alternativet att använda det tillgängliga lediga utrymmet i utmp-strukturen för att lägga till ett ytterligare 64-bitars tidsfält.
Att ändra typbitdjupet i utmp löser dessutom inte andra befintliga problem, som jag också skulle vilja bli av med. Skriva till utmp kräver till exempel särskilda rättigheter, vilket kräver att processer ges ytterligare privilegier. Ett annat problem är att utmp-arkitekturen tillåter lokala användare att utföra DoS-attacker, vilket leder till avbrott i utmp-tjänsten genom manipulering av fillås, vilket gör det omöjligt att vara säker på att innehållet i utmp återspeglar det verkliga tillståndet i systemet. Det föreslogs att använda en ytterligare bakgrundsprocess för att hantera åtkomst till utmp, men för sådana uppgifter finns det redan en systemd-inloggningsprocess och att starta en annan specialiserad process är inte tillrådligt (applikationer måste överföra data till två hanterare samtidigt).
Samtidigt, även när du löser problemet med DoS-attacker, förblir innehållet i utmp endast informativt och garanterar inte en återspegling av verkligheten. Till exempel reflekterar olika emulatorer och terminalmultiplexers deras tillstånd olika - att starta fem GNOME-terminaler kommer att resultera i att en användare reflekteras i utmp, och att starta fem konsole- eller xterm-terminaler i KDE kommer att resultera i sex. Beteendet för skärm och tmux är likadant olika: i det första fallet räknas varje session som en separat användare, och i det andra reflekteras endast en användare för alla sessioner.
Som ett resultat, som den enklaste lösningen, föreslås det att överföra alla applikationer för att använda den redan befintliga alternativa systemd-login-tjänsten och, efter att det inte finns några aktuella program som kommer åt utmp, stoppa inspelningen till utmp. För att ersätta wtmp föreslås att man förbereder mjukvarugränssnitt för att skriva och läsa information om användare som använder systemd-journald. Kodbasen för nästa utgåva av systemd 254 innehåller redan den nödvändiga funktionaliteten för att tillhandahålla utmp-ersättningsdata via libsystemd med sd-login.h API eller via DBUS.
Källa: opennet.ru