Thorsten Kukuk, kiongozi wa kikundi cha maendeleo ya teknolojia ya baadaye katika SUSE (Timu ya Teknolojia ya Baadaye, inakuza OpenSUSE MicroOS na SLE Micro), ambaye hapo awali aliongoza mradi wa SUSE LINUX Enterprise Server kwa miaka 10, alipendekeza kuondokana na /var/run/utmp faili. katika usambazaji ili kushughulikia kikamilifu tatizo la 2038 katika Glibc. Programu zote zinazotumia utmp, wtmp na lastlog zinapendekezwa kubadilishwa ili kupata orodha ya watumiaji wanaotumia systemd-logind.
Tarehe 19 Januari 2038, vihesabio vya muda wa epochal vilivyobainishwa na aina ya 32-bit time_t vitafurika. Glibc, licha ya kutambulisha aina ya 64-bit time_t, inaendelea kutumia aina ya 32-bit time_t katika baadhi ya matukio kwenye mifumo ya 64-bit ili kudumisha upatanifu na programu-tumizi za nafasi ya 32-bit. Kesi moja kama hiyo ni /var/run/utmp faili, ambayo huhifadhi data kuhusu watumiaji walioingia kwenye mfumo kwa sasa. Sehemu ya saa katika utmp imebainishwa kwa kutumia thamani ya 32-bit time_t.
Kubadilisha tu uga wa saa katika utmp kutoka aina ya 32-bit hadi 64-bit haitafanya kazi, kwani hii itasababisha mabadiliko katika Glibc ABI (aina itabadilika katika kazi kama login(), getutid() na utmpname. ()) na kuvunja uoanifu na programu zinazotumia utmp, ikijumuisha w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, wasimamizi wa onyesho la xterm, emacs, openssh, qemu, samba, rsyslog, n.k. Kwa sababu ya wingi wa mitego na utata unaowezekana, wazo la kubadilisha aina ya time_t katika utmp lilikataliwa na wasanidi wa Glibc. Kwa sababu hiyo hiyo, chaguo la kutumia nafasi iliyopo ya bure katika muundo wa utmp ili kuongeza sehemu ya ziada ya 64-bit ilitupwa.
Kwa kuongezea, kubadilisha kina cha aina katika utmp haisuluhishi shida zingine zilizopo, ambazo ningependa pia kuziondoa. Kwa mfano, kuandika kwa utmp kunahitaji ruhusa maalum, ambayo inahitaji michakato ipewe marupurupu ya ziada. Shida nyingine ni kwamba usanifu wa utmp unaruhusu watumiaji wa ndani kufanya shambulio la DoS, na kusababisha usumbufu wa huduma ya utmp kupitia udanganyifu wa kufuli za faili, ambayo inafanya kuwa haiwezekani kuwa na uhakika kuwa yaliyomo kwenye utmp yanaonyesha hali halisi kwenye mfumo. Ilipendekezwa kutumia mchakato wa ziada wa usuli kushughulikia ufikiaji wa utmp, lakini kwa kazi kama hizo tayari kuna mchakato wa kuingia kwa mfumo na kuzindua mchakato mwingine maalum haipendekezi (programu italazimika kuhamisha data kwa vidhibiti viwili kwa wakati mmoja).
Wakati huo huo, hata wakati wa kutatua tatizo na mashambulizi ya DoS, yaliyomo kwenye utmp hubakia habari tu na haihakikishi kutafakari kwa ukweli. Kwa mfano, viigizaji tofauti na vizidishi vya terminal huakisi hali yao kwa njia tofauti - kuzindua vituo vitano vya GNOME kutasababisha mtumiaji mmoja kuakisiwa katika utmp, na kuzindua vituo vitano vya konsole au xterm katika KDE kutasababisha sita. Tabia ya skrini na tmux vile vile ni tofauti: katika kesi ya kwanza, kila kikao huhesabiwa kama mtumiaji tofauti, na kwa pili, mtumiaji mmoja tu ndiye anayeonyeshwa kwa vipindi vyote.
Kama matokeo, kama suluhu rahisi zaidi, inapendekezwa kuhamisha programu zote kutumia huduma mbadala iliyopo tayari ya mfumo wa kuingia na, baada ya kuwa hakuna programu za sasa zinazofikia utmp, acha kurekodi kwa utmp. Ili kuchukua nafasi ya wtmp, inapendekezwa kuandaa violesura vya programu kwa ajili ya kuandika na kusoma taarifa kuhusu watumiaji wanaotumia systemd-journald. Msingi wa msimbo wa toleo lijalo la systemd 254 tayari unajumuisha utendakazi unaohitajika ili kutoa data mbadala ya utmp kupitia libsystemd kwa kutumia sd-login.h API au kupitia DBUS.
Chanzo: opennet.ru