Thorsten Kukuk, vodja skupine za razvoj tehnologije prihodnosti pri SUSE (Future Technology Team, razvija openSUSE MicroOS in SLE Micro), ki je pred tem 10 let vodil projekt SUSE LINUX Enterprise Server, je predlagal, da se znebite datoteke /var/run/utmp v distribucijah za popolno obravnavo težave 2038 v Glibcu. Predlaga se, da se vse aplikacije, ki uporabljajo utmp, wtmp in lastlog, pretvorijo v pridobivanje seznama uporabnikov z uporabo systemd-logind.
19. januarja 2038 bodo epohalni časovni števci, določeni z 32-bitnim tipom time_t, preseženi. Glibc kljub uvedbi 64-bitnega tipa time_t še naprej uporablja 32-bitni tip time_t v nekaterih primerih na 64-bitnih platformah, da ohrani združljivost z 32-bitnimi aplikacijami uporabniškega prostora. Takšen primer je datoteka /var/run/utmp, ki shranjuje podatke o uporabnikih, ki so trenutno prijavljeni v sistem. Časovno polje v utmp je podano z uporabo 32-bitne vrednosti time_t.
Enostavna zamenjava časovnega polja v utmp iz 32-bitnega v 64-bitni tip ne bo delovala, saj bo to povzročilo spremembo v Glibc ABI (tip se bo spremenil v funkcijah, kot so login(), getutid() in utmpname ()) in prekinitev združljivosti z aplikacijami, ki uporabljajo utmp, vključno z w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, upravljalniki zaslona xterm, emacs, openssh, qemu, samba, rsyslog itd. Zaradi obilice možnih pasti in kompleksnosti so razvijalci Glibc zavrnili idejo o zamenjavi tipa time_t v utmp. Iz istega razloga je bila zavržena možnost uporabe razpoložljivega prostega prostora v strukturi utmp za dodajanje dodatnega 64-bitnega časovnega polja.
Poleg tega spreminjanje bitne globine tipa v utmp ne reši drugih obstoječih težav, ki bi se jih prav tako rad znebil. Na primer, pisanje v utmp zahteva posebna dovoljenja, ki zahtevajo, da se procesom dodelijo dodatni privilegiji. Druga težava je, da arhitektura utmp lokalnim uporabnikom omogoča izvajanje napadov DoS, kar vodi do motenj storitve utmp z manipulacijo zaklepanja datotek, zaradi česar je nemogoče biti prepričan, da vsebina utmp odraža resnično stanje v sistemu. Predlagana je bila uporaba dodatnega postopka v ozadju za obdelavo dostopa do utmp, vendar za takšne naloge že obstaja proces systemd-logind in zagon drugega specializiranega procesa ni priporočljiv (aplikacije bodo morale prenesti podatke na dva upravljavca hkrati).
Hkrati tudi pri reševanju problema z napadi DoS vsebina utmp ostane le informativna in ne zagotavlja odseva realnosti. Na primer, različni emulatorji in terminalski multiplekserji različno odražajo svoje stanje - zagon petih terminalov GNOME bo povzročil enega uporabnika, ki bo prikazan v utmp, zagon petih terminalov konzole ali xterm v KDE pa bo povzročil šest. Obnašanje screen in tmux je podobno različno: v prvem primeru se vsaka seja šteje kot ločen uporabnik, v drugem pa se za vse seje odraža le en uporabnik.
Posledično je kot najenostavnejša rešitev predlagan prenos vseh aplikacij na uporabo že obstoječe alternativne storitve systemd-logind in prenehanje snemanja v utmp, ko ni več trenutnih programov, ki bi dostopali do utmp. Za zamenjavo wtmp je predlagana priprava programskih vmesnikov za pisanje in branje informacij o uporabnikih z uporabo systemd-journald. Kodna baza za naslednjo izdajo systemd 254 že vključuje potrebno funkcionalnost za zagotavljanje nadomestnih podatkov utmp prek libsystemd z uporabo sd-login.h API ali prek DBUS.
Vir: opennet.ru