Dėl 2038 metų problemos tais metais dalis programinės įrangos gali sugesti. Problema turi įtakos programoms, kurios naudoja POSIX pagrįstą laiko vaizdavimą.
Thorstenas Kukukas, komandos vadovas iš SUSE Future Technology (Ateities technologijų komanda, kuria openSUSE MicroOS ir SLE Micr ), kuri anksčiau 10 metų vadovavo SUSE LINUX Enterprise Server projektui, pasiūlė atsikratyti /var/run/utmp failo paskirstymuose visiškai išspręsti Y2038 problemą Glibc.
Su tuo siūloma perkelti visas programas, kurios naudoja utmp, wtmp ir lastlog Norėdami gauti vartotojų, naudojančių systemd-logind, sąrašą.
19 m. sausio 2038 d. laikmačiai persipildys nurodyto laikotarpio pagal 32 bitų time_t tipą. Glibc, nepaisant 64 bitų tipo time_t įdiegimo, siekiant išlaikyti suderinamumą su 32 bitų vartotojo erdvės programomis, 32 bitų time_t tipas vis dar naudojamas kai kuriais atvejais 64 bitų platformose.
Yra dvi pagrindinės problemos, susijusios su utmp/utmpx su glibc, pvz., x86-64:
Laikui naudojamas 32 bitų time_t laukas, kuris bus perpildytas 2038 m
Yra dizaino problemų, leidžiančių DoS atakai (utmp/wtmp blokavimas leidžia neprivilegijuotam vartotojui atsisakyti paslaugos)
Glibc kūrėjų atlikta antrosios problemos analizė parodė, kad utmp/utmpx prieigai valdyti reikės papildomo demono.Nors yra ir daugiau problemų...
Vienas iš tokių atvejų yra failas /var/run/utmp, kuriame saugomi duomenys apie šiuo metu prie sistemos prisijungusius vartotojus. Utmp laiko laukas nustatomas naudojant 32 bitų time_t reikšmę.
Minima, kad Laikui bėgant paprasčiausiai pakeisti lauką utmp iš 32 bitų į 64 bitų tipą neveiks, nes tai pakeis Glibc ABI (tipas pasikeis tokiose funkcijose kaip login(), getutid() ir utmpname()) ir nutrauks suderinamumą su programomis, naudojančiomis utmp, įskaitant w, who, uptime, login, su, sudo, useradd , systemd, sysvinit, tcsh, xterm ekranų tvarkyklės, emacs, openssh, qemu, samba, rsyslog ir kt.
Dėl galimų spąstų gausos ir darbštumo, kūrėjai Glibc atmetė idėją pakeisti time_t tipo bitų ilgį utmp. Dėl tos pačios priežasties pašalinta parinktis naudoti utmp struktūroje esančią laisvą vietą, kad būtų galima pridėti papildomą 64 bitų laiko lauką.
Taip pat utmp tipo bitų gylio pakeitimas neišsprendžia kitų esamų problemų, pavyzdžiui, rašant į utmp reikia specialių leidimų, todėl procesams reikia suteikti papildomų privilegijų. Kita problema yra ta, kad utmp architektūra leidžia vietiniams vartotojams atlikti DoS atakas, kurios pažeidžia utmp paslaugą manipuliuodami 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ą, bet tokioms užduotims jau yra systemd-logind procesas ir nerekomenduojama pradėti kito specializuoto proceso (programos vienu metu turės perduoti duomenis dviem valdikliais).
Tuo pačiu, net ir sprendžiant problemą su DoS atakomis, utmp turinys lieka tik informacinis, negarantuojant tikrovės atspindžio.
Pavyzdžiui, skirtingi terminalų emuliatoriai ir tankintuvai skirtingai atspindi savo būseną: naudojant penkis GNOME terminalus, vienas vartotojas bus atspindimas utmp, o naudojant penkis konsolės arba xterm terminalus KDE – šeši. Panašiai skiriasi ekrano ir tmux elgesys: pirmuoju atveju kiekviena sesija skaičiuojama kaip atskiras vartotojas, o antruoju visoms sesijoms rodomas tik vienas vartotojas.
Dėl to kaip paprasčiausias sprendimas siūloma perjungti visas programas, kad galėtų naudotis sistemad-logind paslauga alternatyva jau egzistuoja ir, kai tikros programos nepasiekia utmp, nustokite rašyti į utmp. Norint pakeisti wtmp, siūloma paruošti API informacijai apie vartotojus rašyti ir skaityti naudojant systemd-journald.
Galiausiai verta paminėti, kad kitos versijos kodo bazė systemd 254 jau turi reikiamas funkcijas teikti pakaitinius utmp duomenis per libsystemd naudojant sd-login.ho API per DBUS.
Jei norite sužinoti daugiau apie tai, galite sužinoti daugiau Šioje nuorodoje.