Thorsten Kukuk, leder af Future Technology Team hos SUSE (Future Technology Team, udvikler openSUSE MicroOS og SLE Micro), som tidligere har ledet SUSE LINUX Enterprise Server-projektet i 10 år, foreslog at slippe af med filen /var/run/utmp i distributioner for fuldt ud at løse Y2038-problemet i Glibc. Alle applikationer, der bruger utmp, wtmp og lastlog, foreslås flyttet til at få en liste over brugere, der bruger systemd-login.
Den 19. januar 2038 vil epoketidstællerne, der er specificeret af 32-bit time_t-typen, flyde over. I Glibc, på trods af introduktionen af 64-bit time_t-typen, for at opretholde kompatibilitet med 32-bit user-space-applikationer, bruges 64-bit time_t-typen stadig i nogle tilfælde på 32-bit platforme. Et sådant tilfælde er filen /var/run/utmp, som gemmer data om de brugere, der i øjeblikket er logget ind på systemet. Tidsfeltet i utmp er indstillet ved hjælp af en 32-bit time_t værdi.
Blot at ændre et felt i utmp over tid fra en 32-bit til en 64-bit type vil ikke virke, da dette vil ændre Glibc ABI (typen vil ændre sig i funktioner som login(), getutid() og utmpname()) og bryde kompatibiliteten med programmer, der bruger utmp, inklusive w, who, oppetid, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm display managers, emacs, openssh, qemu, samba, rsyslog osv. På grund af overfloden af mulige faldgruber og besværlighed blev ideen om at erstatte bitlængden af time_t-typen i utmp afvist af udviklerne af Glibc. Af samme grund blev muligheden for at bruge den tilgængelige plads i utmp-strukturen til at tilføje et ekstra 64-bit tidsfelt droppet.
Derudover løser ændring af bitdybden af typen i utmp ikke andre eksisterende problemer, som jeg også gerne vil af med. For eksempel kræver skrivning til utmp særlige tilladelser, hvilket kræver, at der gives yderligere privilegier til processer. Et andet problem er, at utmp-arkitekturen tillader lokale brugere at udføre DoS-angreb, der bryder utmp-tjenesten gennem manipulation af fillåse, hvilket gør det umuligt at være sikker på, at indholdet af utmp afspejler den virkelige tilstand i systemet. Det blev foreslået at bruge en ekstra baggrundsproces til at håndtere adgang til utmp, men for sådanne opgaver er der allerede en systemd-logind-proces, og det er ikke tilrådeligt at starte en anden specialiseret proces (applikationer skal overføre data til to behandlere på samme tid) .
På samme tid, selv når du løser problemet med DoS-angreb, forbliver indholdet af utmp kun informativt, hvilket ikke garanterer en afspejling af virkeligheden. For eksempel afspejler forskellige terminalemulatorer og multipleksere deres tilstand forskelligt - kørsel af fem GNOME-terminaler vil resultere i, at én bruger afspejles i utmp, mens kørsel af fem konsole- eller xterm-terminaler i KDE vil resultere i seks. På samme måde adskiller opførselen af screen og tmux sig, i det første tilfælde tælles hver session som en separat bruger, og i det andet afspejles kun én bruger for alle sessioner.
Som et resultat, som den enkleste løsning, foreslås det at overføre alle applikationer til at bruge den allerede eksisterende alternative systemd-login service og, efter at der ikke er nogen egentlige programmer, der får adgang til utmp, stoppe med at skrive til utmp. For at erstatte wtmp foreslås det at forberede API'er til at skrive og læse information om brugere, der bruger systemd-journald. Kodebasen for den næste udgivelse af systemd 254 indeholder allerede de nødvendige funktioner til at levere erstatnings-utmp-data via libsystemd ved hjælp af sd-login.h API eller via DBUS.
Kilde: opennet.ru