Буга чейин SUSE LINUX Enterprise Server долбоорун 10 жыл жетектеген SUSE (Future Technology Team, openSUSE MicroOS жана SLE Micro иштеп чыгат) Future Technology Team компаниясынын лидери Торстен Кукук /var/run/utmp файлынан кутулууну сунуштады. Glibcдеги Y2038 көйгөйүн толугу менен чечүү үчүн бөлүштүрүү. utmp, wtmp жана lastlog колдонгон бардык тиркемелерди systemd-logind колдонгон колдонуучулардын тизмесин алууга жылдыруу сунушталат.
19-жылдын 2038-январында 32-бит time_t түрү менен белгиленген доордун убакыт эсептегичтери толуп кетет. Glibcде 64 биттик time_t түрүнүн киргизилгенине карабастан, 32 биттик колдонуучу мейкиндик тиркемелери менен шайкештикти сактоо үчүн, 64 биттик time_t түрү дагы эле 32 биттик платформаларда кээ бир учурларда колдонулат. Мындай учурлардын бири /var/run/utmp файлы, ал учурда системага кирген колдонуучулар жөнүндө маалыматтарды сактайт. utmp ичиндеги убакыт талаасы 32-бит time_t маанисин колдонуу менен орнотулган.
Убакыттын өтүшү менен utmp'теги талааны 32-биттен 64-бит түрүнө өзгөртүү иштебейт, анткени бул Glibc ABIди өзгөртөт (түр login(), getutid() жана utmpname() сыяктуу функцияларда өзгөрөт) жана utmp колдонгон тиркемелер менен шайкештикти үзүңүз, анын ичинде w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm дисплей менеджерлери, emacs, openssh, qemu, samba, rsyslog ж.б. Мүмкүн болгон тузактардын жана эмгектин көптүгүнөн улам, utmpдеги time_t түрүнүн бит узундугун алмаштыруу идеясы Glibc иштеп чыгуучулары тарабынан четке кагылган. Ушул эле себептен улам, кошумча 64 бит убакыт талаасын кошуу үчүн utmp түзүмүндөгү жеткиликтүү мейкиндикти колдонуу параметри жокко чыгарылган.
Мындан тышкары, utmp түрүнүн бит тереңдигин өзгөртүү башка көйгөйлөрдү чечпейт, алардан да кутулгум келет. Мисалы, utmpке жазуу процесстерге кошумча артыкчылыктарды берүү үчүн атайын уруксаттарды талап кылат. Дагы бир көйгөй, utmp архитектурасы жергиликтүү колдонуучуларга файл кулпуларын манипуляциялоо аркылуу utmp кызматын бузуп DoS чабуулдарын жасоого мүмкүндүк берет, бул utmp мазмуну системадагы чыныгы абалды чагылдыраарына ишенүүгө мүмкүн эмес. utmp кирүү мүмкүнчүлүгүн иштетүү үчүн кошумча фон процессин колдонуу сунушталды, бирок мындай тапшырмалар үчүн системалык кирүү процесси бар жана башка адистештирилген процессти баштоо максатка ылайыктуу эмес (тиркемелер бир эле учурда эки иштеткичке маалыматтарды өткөрүп бериши керек). .
Ошол эле учурда, DoS чабуулдары менен маселени чечүүдө да, utmp мазмуну чындыктын чагылдырылышына кепилдик бербей, маалыматтык гана бойдон калууда. Мисалы, ар кандай терминалдык эмуляторлор жана мультиплексорлор алардын абалын башкача чагылдырат - беш GNOME терминалын иштетүү бир колдонуучунун utmpде чагылдырылышына алып келет, ал эми KDEде беш konsole же xterm терминалын иштетүү алтыга алып келет. Ошо сыяктуу эле, экрандын жана tmuxтун жүрүм-туруму айырмаланат, биринчи учурда ар бир сеанс өзүнчө колдонуучу катары эсептелет, ал эми экинчисинде бардык сеанстар үчүн бир гана колдонуучу чагылдырылат.
Натыйжада, эң жөнөкөй чечим катары, бардык тиркемелерди мурунтан эле бар альтернативалуу systemd-логин кызматын колдонууга өткөрүп берүү жана utmpке кире турган иш жүзүндө программалар жок болгондон кийин, utmpке жазууну токтотуу сунушталат. Wtmp алмаштыруу үчүн, systemd-journald колдонгон колдонуучулар жөнүндө маалыматты жазуу жана окуу үчүн APIлерди даярдоо сунушталат. systemd 254 кийинки релизинин код базасы sd-login.h API же DBUS аркылуу libsystemd аркылуу utmp маалыматтарды алмаштырууну камсыз кылуу үчүн зарыл функцияларды камтыйт.
Source: opennet.ru