Thorsten Kukuk, leder for fremtidig teknologiutviklingsgruppen ved SUSE (Future Technology Team, utvikler openSUSE MicroOS og SLE Micro), som tidligere ledet SUSE LINUX Enterprise Server-prosjektet i 10 år, foreslo å kvitte seg med /var/run/utmp-filen i distribusjoner for fullt ut å løse 2038-problemet i Glibc. Alle applikasjoner som bruker utmp, wtmp og lastlog foreslås konvertert til å få en liste over brukere som bruker systemd-login.
19. januar 2038 vil epoketidstellerne spesifisert av 32-biters time_t-typen flyte over. Glibc, til tross for å introdusere en 64-bits time_t-type, fortsetter å bruke en 32-bits time_t-type i noen tilfeller på 64-biters plattformer for å opprettholde kompatibilitet med 32-biters brukerplassapplikasjoner. Et slikt tilfelle er filen /var/run/utmp, som lagrer data om brukere som for øyeblikket er logget på systemet. Tidsfeltet i utmp er spesifisert med en 32-biters time_t verdi.
Bare å erstatte tidsfeltet i utmp fra en 32-bit til en 64-bit type vil ikke fungere, da dette vil føre til en endring i Glibc ABI (typen vil endres i funksjoner som login(), getutid() og utmpname ()) og bryter kompatibilitet med applikasjoner som bruker utmp, inkludert w, who, oppetid, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm display managers, emacs, openssh, qemu, samba, rsyslog, etc. På grunn av overfloden av mulige fallgruver og kompleksitet, ble ideen om å erstatte time_t-typen i utmp avvist av Glibc-utviklerne. Av samme grunn ble alternativet for å bruke den tilgjengelige ledige plassen i utmp-strukturen for å legge til et ekstra 64-bits tidsfelt forkastet.
I tillegg løser ikke det å endre typen bitdybde i utmp andre eksisterende problemer, som jeg også gjerne vil bli kvitt. For eksempel krever skriving til utmp spesielle rettigheter, noe som krever at prosesser gis tilleggsrettigheter. Et annet problem er at utmp-arkitekturen lar lokale brukere utføre DoS-angrep, noe som fører til forstyrrelse av utmp-tjenesten gjennom manipulering av fillåser, noe som gjør det umulig å være sikker på at innholdet i utmp gjenspeiler den virkelige tilstanden i systemet. Det ble foreslått å bruke en ekstra bakgrunnsprosess for å håndtere tilgang til utmp, men for slike oppgaver er det allerede en systemd-påloggingsprosess, og det er ikke tilrådelig å starte en annen spesialisert prosess (applikasjoner vil måtte overføre data til to behandlere samtidig).
Samtidig, selv når du løser problemet med DoS-angrep, forblir innholdet i utmp kun informativt og garanterer ikke en refleksjon av virkeligheten. For eksempel reflekterer forskjellige emulatorer og terminalmultipleksere deres tilstand forskjellig - å starte fem GNOME-terminaler vil resultere i at én bruker reflekteres i utmp, og å starte fem konsole- eller xterm-terminaler i KDE vil resultere i seks. Oppførselen til skjerm og tmux er på samme måte forskjellig: i det første tilfellet regnes hver økt som en separat bruker, og i den andre reflekteres bare én bruker for alle økter.
Som et resultat, som den enkleste løsningen, foreslås det å overføre alle applikasjoner til å bruke den allerede eksisterende alternative systemd-login-tjenesten og, etter at det ikke er noen nåværende programmer som har tilgang til utmp, stoppe opptaket til utmp. For å erstatte wtmp foreslås det å utarbeide programvaregrensesnitt for å skrive og lese informasjon om brukere som bruker systemd-journald. Kodebasen for neste utgivelse av systemd 254 inkluderer allerede den nødvendige funksjonaliteten for å gi utmp-erstatningsdata via libsystemd ved å bruke sd-login.h API eller via DBUS.
Kilde: opennet.ru