Kako bi se Glibc riješio problema 2038, predlaže se prestanak korištenja utmp-a

Thorsten Kukuk, voditelj grupe za budući tehnološki razvoj u SUSE-u (Future Technology Team, razvija openSUSE MicroOS i SLE Micro), koji je prethodno vodio SUSE LINUX Enterprise Server projekt 10 godina, predložio je uklanjanje /var/run/utmp datoteke u distribucijama za potpuno rješavanje problema 2038 u Glibcu. Predlaže se da se sve aplikacije koje koriste utmp, wtmp i lastlog pretvore u dobivanje popisa korisnika pomoću systemd-logind.

Dana 19. siječnja 2038. brojači epohalnog vremena specificirani 32-bitnim time_t tipom će se preliti. Glibc, unatoč uvođenju 64-bitnog tipa time_t, nastavlja koristiti 32-bitni tip time_t u nekim slučajevima na 64-bitnim platformama kako bi održao kompatibilnost s 32-bitnim aplikacijama korisničkog prostora. Jedan takav slučaj je /var/run/utmp datoteka, koja pohranjuje podatke o korisnicima koji su trenutno prijavljeni u sustav. Vremensko polje u utmp navedeno je pomoću 32-bitne vrijednosti time_t.

Jednostavna zamjena vremenskog polja u utmp-u s 32-bitnog na 64-bitni tip neće funkcionirati jer će to dovesti do promjene u Glibc ABI-ju (tip će se promijeniti u funkcijama kao što su login(), getutid() i utmpname ()) i kršenje kompatibilnosti s aplikacijama koje koriste utmp, uključujući w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm display managers, emacs, openssh, qemu, samba, rsyslog itd. Zbog obilja mogućih zamki i složenosti, programeri Glibc-a su odbacili ideju o zamjeni tipa time_t u utmp. Iz istog je razloga odbačena opcija korištenja slobodnog prostora u utmp strukturi za dodavanje dodatnog 64-bitnog vremenskog polja.

Osim toga, promjena bitne dubine tipa u utmp ne rješava druge postojeće probleme, kojih bih se također želio riješiti. Na primjer, pisanje u utmp zahtijeva posebna prava, što zahtijeva da procesi dobiju dodatne privilegije. Drugi problem je što utmp arhitektura dopušta lokalnim korisnicima izvođenje DoS napada, što dovodi do prekida utmp usluge kroz manipulaciju zaključavanja datoteka, što onemogućuje sigurnost da sadržaj utmp odražava stvarno stanje u sustavu. Predloženo je korištenje dodatnog pozadinskog procesa za rukovanje pristupom utmp-u, ali za takve zadatke već postoji systemd-logind proces i pokretanje drugog specijaliziranog procesa nije preporučljivo (aplikacije će morati prenijeti podatke na dva rukovatelja istovremeno).

U isto vrijeme, čak i kada se rješava problem s DoS napadima, sadržaj utmp-a ostaje samo informativan i ne jamči odraz stvarnosti. Na primjer, različiti emulatori i terminalski multiplekseri različito odražavaju svoje stanje - pokretanje pet GNOME terminala rezultirat će s prikazom jednog korisnika u utmp-u, a pokretanje pet terminala konzole ili xterm u KDE-u rezultirat će sa šest. Ponašanje screena i tmuxa slično je različito: u prvom slučaju svaka se sesija broji kao zasebni korisnik, au drugom se samo jedan korisnik odražava za sve sesije.

Kao rezultat toga, kao najjednostavnije rješenje, predlaže se prebacivanje svih aplikacija na korištenje već postojeće alternativne usluge systemd-logind i, nakon što nema trenutačnih programa koji pristupaju utmp-u, zaustavljanje snimanja na utmp. Kako bi se zamijenio wtmp, predlaže se priprema softverskih sučelja za pisanje i čitanje informacija o korisnicima pomoću systemd-journalda. Baza koda za sljedeće izdanje systemd 254 već uključuje potrebnu funkcionalnost za pružanje utmp zamjenskih podataka putem libsystemd koristeći sd-login.h API ili putem DBUS-a.

Izvor: opennet.ru

Dodajte komentar