Thorsten Kukuk, lieder fan 'e takomstige technologyûntwikkelingsgroep by SUSE (Future Technology Team, ûntwikkelet openSUSE MicroOS en SLE Micro), dy't earder it SUSE LINUX Enterprise Server-projekt foar 10 jier liede, stelde foar om it /var/run/utmp-bestân kwyt te reitsjen yn distribúsjes om it 2038-probleem yn Glibc folslein oan te pakken. Alle applikaasjes dy't utmp, wtmp en lastlog brûke, wurde foarsteld om te konvertearjen om in list mei brûkers te krijen mei systemd-login.
Op 19 jannewaris 2038 sille de epochale tiidtellers spesifisearre troch it 32-bit time_t-type oerrinne. Glibc, nettsjinsteande it yntrodusearjen fan in 64-bit time_t-type, bliuwt yn guon gefallen in 32-bit time_t-type te brûken op 64-bit platfoarms om kompatibiliteit te behâlden mei 32-bit brûkersromteapplikaasjes. Ien sa'n gefal is de /var/run/utmp-bestân, dy't gegevens bewarret oer brûkers dy't op it stuit ynlogd binne yn it systeem. It tiidfjild yn utmp wurdt oantsjutte mei in 32-bit time_t wearde.
It gewoan ferfangen fan it tiidfjild yn utmp fan in 32-bit nei in 64-bit type sil net wurkje, om't dit sil liede ta in feroaring yn 'e Glibc ABI (it type sil feroarje yn funksjes lykas login (), getutid () en utmpname ()) en kompatibiliteit brekke mei applikaasjes dy't utmp brûke, ynklusyf w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm display managers, emacs, openssh, qemu, samba, rsyslog, ensfh. Fanwegen de oerfloed fan mooglike falkûlen en kompleksiteit waard it idee om it time_t-type yn utmp te ferfangen ôfwiisd troch de Glibc-ûntwikkelders. Om deselde reden waard de opsje fan it brûken fan de beskikbere frije romte yn 'e utmp-struktuer om in ekstra 64-bit tiidfjild ta te foegjen wegere.
Dêrnjonken lost it feroarjen fan it type bitdjipte yn utmp gjin oare besteande problemen op, dy't ik ek graach kwyt wolle. Bygelyks, skriuwen nei utmp fereasket spesjale tagongsrjochten, wat fereasket dat prosessen ekstra privileezjes wurde takend. In oar probleem is dat de utmp-arsjitektuer lokale brûkers mooglik makket om DoS-oanfallen út te fieren, wat liedt ta fersteuring fan 'e utmp-tsjinst troch manipulaasje fan bestânslûzen, wat it ûnmooglik makket om der wis fan te wêzen dat de ynhâld fan utmp de echte steat yn it systeem reflektearret. It waard foarsteld om in ekstra eftergrûnproses te brûken om tagong ta utmp te behanneljen, mar foar sokke taken is d'r al in systemd-login-proses en it is net oan te rieden om in oar spesjalisearre proses te starten (applikaasjes sille gegevens tagelyk moatte oerdrage oan twa handlers).
Tagelyk, sels by it oplossen fan it probleem mei DoS-oanfallen, bliuwt de ynhâld fan utmp allinich ynformatyf en garandearje gjin refleksje fan 'e realiteit. Bygelyks, ferskillende emulators en terminal multiplexers wjerspegelje harren steat oars - it starten fan fiif GNOME terminals sil resultearje yn ien brûker wurdt wjerspegele yn utmp, en it starten fan fiif konsole of xterm terminals yn KDE sil resultearje yn seis. It gedrach fan skerm en tmux is lykwols oars: yn it earste gefal wurdt elke sesje as in aparte brûker rekkene, en yn 'e twadde wurdt mar ien brûker foar alle sesjes reflektearre.
As gefolch, as de ienfâldichste oplossing, wurdt it foarsteld om alle applikaasjes oer te dragen om de al besteande alternative systemd-login tsjinst te brûken en, nei't d'r gjin aktuele programma's binne dy't tagong hawwe ta utmp, stopje mei opnimmen nei utmp. Om wtmp te ferfangen, wurdt it foarsteld om software-ynterfaces te meitsjen foar it skriuwen en lêzen fan ynformaasje oer brûkers mei systemd-journald. De codebase foar de folgjende release fan systemd 254 omfettet al de nedige funksjonaliteit om utmp-ferfangingsgegevens te leverjen fia libsystemd mei de sd-login.h API of fia DBUS.
Boarne: opennet.ru