För att avlägsna Glibc från 2038-problemet föreslås det att sluta använda utmp

Thorsten Kukuk, ledare för Future Technology Team på SUSE, som utvecklar openSUSE MicroOS och SLE Micro, och tidigare lett SUSE LINUX Enterprise Server-projektet i 10 år, föreslog att ta bort filen /var/run/utmp i distributioner för att helt lösa problematiken kring år 2038 i Glibc. Det föreslås att alla applikationer som använder utmp, wtmp och lastlog istället ska hämta användarlistor genom systemd-logind.

Den 19 januari 2038 kommer det att ske en överflödesproblem relaterat till tidsräkningssystemet, som anges av den 32-bitars typ av time_t. I Glibc-biblioteket, trots införandet av en 64-bitars typ av time_t, används i vissa fall 32-bitars typen fortfarande på 64-bitars plattformar för att säkerställa kompatibilitet med 32-bitars applikationer. 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 definieras med ett 32-bitars värde av time_t.

Det är inte möjligt att enkelt ändra tidsfältet i utmp från 32-bitars till 64-bitars typen, eftersom detta skulle leda till en ändring av ABI Glibc (typ i funktioner som login(), getutid() och utmpname()) och bryta kompatibiliteten med applikationer som använder utmp, inklusive w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm, grafiska användargränssnitt, emacs, openssh, qemu, samba, rsyslog etc. På grund av de många potentiella fallgroparna och arbetsinsatsen avvisades idén att byta tidstypens bitdjup i utmp av Glibc-utvecklarna. Av samma anledning avfärdades även alternativet att använda det fria utrymmet i utmp-strukturen för att lägga till ett extra 64-bitars tidsfält.

Dessutom löser inte ändringen av typens bitdjup i utmp andra befintliga problem som också skulle behöva åtgärdas. Till exempel krävs särskilda rättigheter för att skriva till utmp, vilket innebär att processerna måste ges ytterligare privilegier. Ett annat problem är att utmp-arkitekturen tillåter lokala användare att genomföra DoS-attacker, vilket kan leda till att utmp-tjänsten störs genom manipulation av filens lås, vilket gör att man inte kan vara säker på att innehållet i utmp speglar det verkliga tillståndet i systemet. För att hantera åtkomsten till utmp föreslogs att använda en extra bakgrundsprocess, men för sådana uppgifter finns det redan processen systemd-logind och att starta ytterligare en specialiserad process är inte rimligt (applikationer måste överföra data till två hanterare samtidigt).

Även om problemet med DoS-attacker löses förblir innehållet i utmp endast informativt och ger ingen garanti för att spegla verkligheten. Till exempel visar olika terminalemulatorer och multiplexorer på olika sätt sitt tillstånd — att starta fem GNOME-terminaler kommer att resultera i att utmp visar en användare, medan att starta fem terminaler med konsole eller xterm i KDE visar sex. Beteendet för screen och tmux skiljer sig också åt; i det första fallet räknas varje session som en separat användare, medan i det andra bara en användare visas för alla sessioner.

Som en enkel lösning föreslås att alla applikationer övergår till att använda den befintliga alternativa tjänsten systemd-logind och efter att inga aktuella program som använder utmp finns kvar, sluta skriva till utmp. För att ersätta wtmp föreslås att programgränssnitt för att skriva och läsa information om användare utarbetas med hjälp av systemd-journald. De nödvändiga funktionerna för att tillhandahålla ersättande utmp-data via libsystemd med hjälp av API sd-login.h eller via DBUS har redan inkluderats i kodbasen för nästa version av systemd 254.

Källa: opennet.ru