Thorsten Kukuk, leder af Future Technology Team hos SUSE, der udvikler openSUSE MicroOS og SLE Micro, og tidligere leder af SUSE LINUX Enterprise Server i 10 år, har foreslået at fjerne filen /var/run/utmp fra distributionerne for fuldstændig at løse 2038-problemet i Glibc. Det foreslås, at alle applikationer, der bruger utmp, wtmp og lastlog, overgår til at hente brugerlisten via systemd-logind.
Den 19. januar 2038 vil der ske et overflow af epoch-tællere, defineret af den 32-bit type time_t. I Glibc-biblioteket, på trods af introduktionen af 64-bit type time_t, bliver den 32-bit type time_t i visse tilfælde fortsat brugt på 64-bit platforme for at bevare kompatibiliteten med 32-bit applikationer. Et af disse tilfælde er filen /var/run/utmp, der gemmer data om brugere, der i øjeblikket arbejder i systemet. Tidsfeltet i utmp er defineret ved hjælp af et 32-bit time_t-værdi.
Det er ikke muligt blot at ændre tidsfeltet i utmp fra 32-bit til 64-bit type, da det vil medføre en ændring af ABI i Glibc (typen vil ændre sig i funktioner som login(), getutid() og utmpname()) og bryde kompatibiliteten med applikationer, der bruger utmp, herunder w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm display managers, emacs, openssh, qemu, samba, rsyslog osv. På grund af de mange mulige faldgruber og det krævende arbejde blev ideen om at ændre bitdybden af time_t i utmp forkastet af Glibc-udviklerne. Af samme grund blev muligheden for at bruge det frie rum i utmp-strukturen til at tilføje et ekstra 64-bit tidsfelt også forkastet.
Derudover løser ændringen af typen i utmp ikke de andre eksisterende problemer, som vi også gerne vil fjerne. For eksempel kræver registrering i utmp særlige rettigheder, hvilket kræver, at processer gives ekstra privilegier. En anden problematik er, at arkitekturen i utmp tillader lokale brugere at udføre DoS-angreb, hvilket fører til forstyrrelse af utmp-tjenesten gennem manipulation med filens låsninger, hvilket skaber usikkerhed om, at indholdet af utmp afspejler den virkelige tilstand i systemet. Der var forslag om at bruge en ekstra baggrundsproces til at håndtere adgangen til utmp, men til sådanne opgaver eksisterer systemd-logind allerede, og det ville ikke være fornuftigt at starte endnu en specialiseret proces (applikationer ville skulle sende data til to håndteringsprocesser samtidig).
Selv ved løsning af problemet med DoS-angreb forbliver indholdet af utmp kun informativt og garanterer ikke en ægte afspejling af virkeligheden. For eksempel afspejler forskellige emulatorer og multiplexere af terminaler deres tilstand forskelligt — lanceringen af fem GNOME-terminaler resulterer i registrering af én bruger i utmp, mens lanceringen af fem terminaler i konsole eller xterm i KDE — seks. Adfærden for screen og tmux adskiller sig også; i det første tilfælde tælles hver session som en separat bruger, mens en enkelt bruger kun afspejles på tværs af alle sessioner i det andet case.
Som det mest enkle løsninger foreslås det at overføre alle applikationer til at bruge den allerede eksisterende alternative tjeneste systemd-logind, og når der ikke længere er aktuelle programmer, der henvender sig til utmp, ophøre med at registrere i utmp. For at erstatte wtmp foreslås det at forberede programmeringsgrænseflader til at skrive og læse oplysninger om brugere via systemd-journald. De nødvendige funktioner til at levere erstatning av utmp-data gennem libsystemd med brug af API sd-login.h eller via DBUS er allerede inkluderet i kodebasen for den næste version af systemd 254.
Kilde: opennet.ru
