Thorsten Kukuk, tulevikutehnoloogiate arendusteam SUSE's (Future Technology Team, arendab openSUSE MicroOS ja SLE Micro), kes juhtis varem 10 aastat projekti SUSE LINUX Enterprise Server, soovitas eemaldada faili /var/run/utmp distributsioonidest, et täielikult lahendada 2038. aasta probleem Glibcis. Kõik rakendused, mis kasutavad utmp, wtmp ja lastlog, tuleks viia üle kasutajate nimekirja hankimisele süsteemi kaudu systemd-logind.
19. jaanuaril 2038 toimub ajamõõtude ületäitumine, mis on määratud 32-bitise time_t tüübi järgi. Glibci teegis, vaatamata 64-bitise time_t tüübi kasutuselevõtule, jätkab mõnel juhul 32-bitise time_t tüübi kasutamine kasutaja ruumi kokkusobivuse tagamiseks 32-bitiste rakendustega, sealhulgas failis /var/run/utmp, mis säilitab andmed kasutajate kohta, kes praegu süsteemis töötavad. Utmp-s olev ajaväli määratakse 32-bitise time_t väärtuse abil.
Ainult 32-bit tüübi asendamine 64-bitise tüübiga utmp-s ei tööta, kuna see toob kaasa Glibci ABI muutumise (funktsioonide, nagu login(), getutid() ja utmpname() tüüp muutub) ja rikub ühilduvust rakendustega, mis kasutavad utmp, sealhulgas w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm, kuvajuhid, emacs, openssh, qemu, samba, rsyslog jne. Tänu paljudele võimalikele takistustele ja töömahukusele, loobusid Glibci arendajad ideest asendada utmp-s time_t tüübi bitsus. Sama põhjusel lükati tagasi ka variant kasutada struktuuris utmp olevat vaba ruumi, et lisada täiendav 64-bitine ajaväli.
Lisaks ei lahenda utmp tüübi bitisügavuse muutmine muid olemasolevaid probleeme, millest tahaksime samuti vabaneda. Näiteks vajavad kirjed utmp-s spetsiaalseid õigusi, mis nõuab protsesside täiendavate privileegide andmist. Veel üks probleem on seotud sellega, et utmp arhitektuur võimaldab kohalikel kasutajatel tekitada DoS-rünnakuid, mis võivad põhjustada utmp teenuse katkemist, manipuleerimise läbi faili lukustustega, mistõttu ei saa olla kindel, et utmp sisu peegeldab süsteemis tegelikku seisundit. Utmp juurde pääsemiseks on soovitatud kasutada lisaprotsessi, kuid selliste ülesannete jaoks on juba olemas process systemd-logind, ning veel ühe spetsialiseeritud protsessi käivitamine ei ole mõttekas (rakendused peavad edastama andmeid samaaegselt kahele töötlejale).
Sellegipoolest, isegi kui DoS-rünnakuid lahendatakse, jääb utmp sisu vaid informatiivseks, mis ei garanteeri reaalsuse peegeldust. Näiteks erinevad terminaliemulaatorid ja mitmeotstarbelised terminalid kajastavad oma olekut erinevalt — viie GNOME terminali käivitamine toob utmp-sse esindama üht kasutajat, samas kui viis KDE terminali, nagu konsole või xterm, kajastavad kuut. Sarnaselt erineb ka screen ja tmux käitumine: esimesel juhul arvestatakse iga seanss eraldi kasutajana, samas kui teisel kajastatakse kõiki seanse ühe kasutajana.
Kokkuvõttes pakutakse kõige lihtsamat lahendust, milleks on kõigi rakenduste üleviimine juba olemasoleva alternatiivteenuse systemd-logind kasutamisele ja pärast seda, kui ei jää enam aktiivseid programme, mis pöördub utmp poole, lõpetada utmp-sse kirjutamine. wtmp asendamiseks soovitatakse luua tarkvaraliideseid kasutajate teabe kirjutamiseks ja lugemiseks systemd-journald abil. Järgmise versioni systemd 254 koodibaasi on juba integreeritud vajalikud funktsioonid, et pakkuda asendavaid utmp andmeid läbi libsystemd, kasutades API sd-login.h või läbi DBUS.
Allikas: opennet.ru
