Thorsten Kukuk, tuleviku tehnoloogiate arengu grupi juht ettevõttes SUSE, kes arendab openSUSE MicroOS ja SLE Micro, pakkus välja, et distsipliinides tuleks loobuda failist /var/run/utmp, et täielikult lahendada 2038. aasta probleem Glibc-s. Kõiki rakendusi, mis kasutavad utmp, wtmp ja lastlog, soovitatakse suunata kasutajate loendi saamiseks systemd-logindile.
19. jaanuaril 2038 toimub ajamotiivide arvu üleujutus, mis on määratud 32-bitise time_t tüübi järgi. Glibc raamatukogus, vaatamata 64-bitise time_t tüübi kasutuselevõtule, säilitatakse 32-bitise time_t tüübi ühilduvuse tagamiseks mõnes kasutaja ruumis 64-bitistes keskkondades. Üks selline juhtum on fail /var/run/utmp, mis salvestab andmed kasutajatest, kes on praegu süsteemis töös. Aja väli utmp-s määratakse 32-bitise time_t väärtusega.
Ainult utmp-s aja välja asendamine 32-bitisega 64-bitise tüübiga ei ole võimalik, kuna see tooks kaasa Glibc ABI muutumise (tugevus muutub funktsioonides, nagu login(), getutid() ja utmpname()) ja rikuks ühilduvust rakendustega, mis kasutavad utmp-i, sealhulgas w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm graafikuhaldurid, emacs, openssh, qemu, samba, rsyslog jne. Paljude potentsiaalsete probleemide tõttu ning töö mahukuse tõttu lükati idee utmp-s time_t tüübi muutmiseks Glibc arendajate poolt tagasi. Sama põhjuse tõttu lükati tagasi ka võimalus kasutada struktuuris utmp olemasolevat vaba ruumi täiendava 64-bitise aja välja lisamiseks.
Lisaks ei lahenda tüübi bittide muutmine utmp-s muid olemasolevaid probleeme, millest soovitakse samuti vabaneda. Näiteks nõuab utmp-sse kirjutamiseks spetsiaalseid õigusi, mis nõuab protsesside täiendavate privileegide andmist. Teine probleem on seotud sellega, et utmp arhitektuur võimaldab kohalike kasutajate DoS-rünnakuid, mis viib utmp teenuse töö katkemiseni failide lukustamisega manipuleerimise tõttu, mistõttu ei saa olla kindel, et utmp sisu kajastab süsteemi tegelikku seisukorda. Utmp juurde pääsemiseks on soovitatud kasutada täiendavat taustaprotsessi, kuid selliste ülesannete jaoks on juba olemas systemd-logind protsess ja veel ühe spetsialiseeritud protsessi käivitamine ei ole otstarbekas (rakendustel tuleb edastada andmeid samaaegselt kahe töötleja juurde).
Isegi kui DoS-rünnaku probleem on lahendatud, jääb utmp sisu ainult informatiivseks, mis ei garanteeri tegelikkuse kajastamist. Näiteks erinevad emulaatorid ja terminali multiplexers kajastavad oma seisundit erinevalt - viie GNOME terminali käivitamine toob utmp-sse ainult ühe kasutaja, samas kui viie konsooli või xterm'i käivitamine KDE-s toob kuus. Samuti erineb käitumine screen-i ja tmux-i puhul, kus esimesel juhul arvestatakse iga seanss eraldi kasutajana, samas kui teisel juhul kajastub kõikide seansside kohta ainult üks kasutaja.
Lõpuks pakutakse kõige lihtsama lahendusena kõigi rakenduste üleviimist juba olemasoleva alternatiivse teenuse systemd-logind kasutusse ja pärast seda, kui pole enam aktuaalseid programme, mis pöörduvad utmp poole, lõpetada utmp-sse kirjutamine. Wtmp asendamiseks soovitatakse ette valmistada tarkvaraliideseid kasutajainformatsiooni kirjutamiseks ja lugemiseks systemd-journald abil. Järgmise systemd 254 väljaande koodibaasi on juba kaasatud vajalikud funktsioonid, et pakkuda asendavaid utmp andmeid läbi libsystemd sd-login.h API või DBUS-i kaudu.
Allikas: opennet.ru
