Daha əvvəl SUSE LINUX Enterprise Server layihəsinə 10 il rəhbərlik etmiş SUSE (Gələcək Texnologiya Komandası, openSUSE MicroOS və SLE Micro inkişaf etdirir) Gələcək Texnologiya Komandasının lideri Thorsten Kukuk, /var/run/utmp faylından xilas olmağı təklif etdi. Glibc-də Y2038 problemini tam həll etmək üçün paylamalar. Utmp, wtmp və lastlog istifadə edən bütün proqramların systemd-logind istifadə edən istifadəçilərin siyahısını əldə etmək üçün köçürülməsi təklif olunur.
19 yanvar 2038-ci ildə 32 bitlik time_t növü ilə müəyyən edilmiş dövr vaxtı sayğacları daşacaq. Glibc-də, 64-bit time_t növünün tətbiqinə baxmayaraq, 32-bitlik istifadəçi məkanı tətbiqləri ilə uyğunluğu qorumaq üçün, 64-bit time_t növü hələ də bəzi hallarda 32-bit platformalarda istifadə olunur. Belə hallardan biri hazırda sistemə daxil olmuş istifadəçilər haqqında məlumatları saxlayan /var/run/utmp faylıdır. utmp-də vaxt sahəsi 32 bitlik time_t dəyərindən istifadə etməklə təyin edilir.
Sadəcə olaraq utmp-da sahəni 32-bit tipdən 64-bit tipə zamanla dəyişmək işləməyəcək, çünki bu, Glibc ABI-ni dəyişəcək (növ login(), getutid() və utmpname() kimi funksiyalarda dəyişəcək. ) və w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm displey menecerləri, emacs, openssh, qemu, samba, rsyslog və s. daxil olmaqla utmp istifadə edən proqramlarla uyğunluğu pozun. Mümkün tələlərin çoxluğu və zəhmətkeşliyi səbəbindən utmp-də time_t növünün bit uzunluğunu əvəz etmək fikri Glibc tərtibatçıları tərəfindən rədd edildi. Eyni səbəbdən, əlavə 64 bitlik vaxt sahəsi əlavə etmək üçün utmp strukturunda mövcud boşluqdan istifadə etmək seçimi ləğv edildi.
Bundan əlavə, utmp-də növün bit dərinliyinin dəyişdirilməsi digər mövcud problemləri həll etmir, mən də onlardan qurtulmaq istərdim. Məsələn, utmp-a yazmaq xüsusi icazələr tələb edir ki, bu da proseslərə əlavə imtiyazların verilməsini tələb edir. Digər problem odur ki, utmp arxitekturası yerli istifadəçilərə fayl kilidləri ilə manipulyasiya yolu ilə utmp xidmətini pozan DoS hücumları həyata keçirməyə imkan verir ki, bu da utmp məzmununun sistemdəki real vəziyyəti əks etdirdiyinə əmin olmağı qeyri-mümkün edir. Utmp-a girişi idarə etmək üçün əlavə fon prosesindən istifadə etmək təklif edildi, lakin bu cür tapşırıqlar üçün artıq sistemli giriş prosesi mövcuddur və başqa bir xüsusi prosesə başlamaq məqsədəuyğun deyil (tətbiqlər eyni anda iki işləyiciyə məlumat ötürməli olacaq) .
Eyni zamanda, DoS hücumları ilə problemi həll edərkən belə, utmp məzmunu reallığın əks olunmasına zəmanət vermir, yalnız məlumat xarakteri daşıyır. Məsələn, müxtəlif terminal emulyatorları və multipleksorları onların vəziyyətini fərqli şəkildə əks etdirir - beş GNOME terminalının işlədilməsi bir istifadəçinin utmp-də əks olunması ilə nəticələnəcək, KDE-də beş konsol və ya xterm terminalının işləməsi isə altı ilə nəticələnəcək. Eynilə, ekran və tmux-un davranışı fərqlənir, birinci halda hər bir seans ayrıca istifadəçi kimi sayılır, ikincidə isə bütün seanslar üçün yalnız bir istifadəçi əks olunur.
Nəticədə, ən sadə həll yolu kimi, artıq mövcud alternativ sistemd-logind xidmətindən istifadə etmək üçün bütün proqramları köçürmək və utmp-ə daxil olan faktiki proqramlar olmadıqda, utmp-ə yazmağı dayandırmaq təklif olunur. Wtmp-i əvəz etmək üçün systemd-journald-dan istifadə edən istifadəçilər haqqında məlumatların yazılması və oxunması üçün API-lərin hazırlanması təklif olunur. Systemd 254-ün növbəti buraxılışı üçün kod bazası artıq sd-login.h API və ya DBUS vasitəsilə libsystemd vasitəsilə utmp məlumatlarının dəyişdirilməsini təmin etmək üçün lazımi funksiyaları ehtiva edir.
Mənbə: opennet.ru