Norint atsikratyti Glibc nuo 2038 problemos, siūloma nustoti naudoti utmp

Thorstenas Kukukas, SUSE ateities technologijų plėtros grupės vadovas (Future Technology Team, kuria openSUSE MicroOS ir SLE Micro), anksčiau 10 metų vadovavęs SUSE LINUX Enterprise Server projektui, pasiūlė atsikratyti /var/run/utmp failo. paskirstymuose, kad būtų visiškai išspręsta 2038 problema Glibc. Visas programas, kurios naudoja utmp, wtmp ir lastlog, siūloma konvertuoti į vartotojų sąrašo gavimą naudojant systemd-logind.

19 m. sausio 2038 d. epochinio laiko skaitikliai, nurodyti 32 bitų time_t tipo, bus perpildyti. Glibc, nepaisant to, kad įdiegė 64 bitų time_t tipą, kai kuriais atvejais ir toliau naudoja 32 bitų time_t tipą 64 bitų platformose, kad išlaikytų suderinamumą su 32 bitų vartotojo erdvės programomis. Vienas iš tokių atvejų yra /var/run/utmp failas, kuriame saugomi duomenys apie šiuo metu prie sistemos prisijungusius vartotojus. Laiko laukas utmp nurodomas naudojant 32 bitų time_t reikšmę.

Paprasčiausias laiko lauko utmp pakeitimas iš 32 bitų į 64 bitų tipą neveiks, nes pasikeis Glibc ABI (tipas pasikeis tokiose funkcijose kaip login(), getutid() ir utmpname ()) ir sulaužyti suderinamumą su programomis, naudojančiomis utmp, įskaitant w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm ekrano tvarkykles, emacs, openssh, qemu, samba, rsyslog ir kt. Dėl daugybės galimų spąstų ir sudėtingumo „Glibc“ kūrėjai atmetė idėją pakeisti time_t tipą utmp. Dėl tos pačios priežasties buvo atmesta galimybė naudoti turimą laisvą vietą utmp struktūroje norint pridėti papildomą 64 bitų laiko lauką.

Be to, utmp tipo bitų gylio pakeitimas neišsprendžia kitų esamų problemų, kurių taip pat norėčiau atsikratyti. Pavyzdžiui, norint rašyti į utmp reikia specialių leidimų, todėl procesams reikia suteikti papildomų privilegijų. Kita problema yra ta, kad utmp architektūra leidžia vietiniams vartotojams vykdyti DoS atakas, dėl kurių gali sutrikti utmp paslauga manipuliuojant failų užraktais, todėl neįmanoma įsitikinti, kad utmp turinys atspindi tikrąją sistemos būseną. Prieigai prie utmp buvo pasiūlyta naudoti papildomą foninį procesą, tačiau tokioms užduotims jau yra systemd-logind procesas, o pradėti kitą specializuotą procesą nepatartina (programos vienu metu turės perduoti duomenis dviem tvarkytojams).

Tuo pačiu metu, net ir sprendžiant problemą su DoS atakomis, utmp turinys lieka tik informacinis ir negarantuoja tikrovės atspindžio. Pavyzdžiui, skirtingi emuliatoriai ir terminalų tankintuvai skirtingai atspindi savo būseną – paleidus penkis GNOME terminalus, vienas vartotojas bus rodomas utmp, o paleidus penkis konsolės arba xterm terminalus KDE – šeši. Ekrano ir tmux elgsena panašiai skiriasi: pirmuoju atveju kiekviena sesija skaičiuojama kaip atskiras vartotojas, o antruoju – visose sesijose atsispindi tik vienas vartotojas.

Dėl to, kaip paprasčiausią sprendimą, siūloma visas programas perkelti naudoti jau egzistuojančią alternatyvią systemd-logind paslaugą ir, kai nėra dabartinių programų, pasiekiančių utmp, sustabdyti įrašymą į utmp. Norint pakeisti wtmp, siūloma parengti programinės įrangos sąsajas informacijai apie vartotojus rašyti ir skaityti naudojant systemd-journald. Kitos „systemd 254“ laidos kodų bazėje jau yra būtinos funkcijos, leidžiančios teikti „utmp“ pakeitimo duomenis per „libsystemd“, naudojant sd-login.h API arba per DBUS.

Šaltinis: opennet.ru

Добавить комментарий