Бұрын SUSE LINUX Enterprise Server жобасын 10 жыл бойы басқарған SUSE (Future Technology Team, openSUSE MicroOS және SLE Micro әзірлейді) болашақ технологиялар тобының жетекшісі Торстен Кукук /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 және т.б. үйлесімділігін бұзу. Мүмкін болатын қателіктер мен еңбекқорлықтың көптігіне байланысты Glibc әзірлеушілері utmp ішіндегі time_t түрінің бит ұзындығын ауыстыру идеясын қабылдамады. Дәл сол себепті қосымша 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 деректерін ауыстыруды қамтамасыз ету үшін қажетті функцияларды қамтиды.
Ақпарат көзі: opennet.ru