SUSE (Future Technology Team, develops openSUSE MicroOS සහ SLE Micro) හි අනාගත තාක්ෂණ සංවර්ධන කණ්ඩායමේ නායක Thorsten Kukuk, මීට පෙර වසර 10ක් SUSE LINUX Enterprise Server ව්‍යාපෘතිය මෙහෙයවූ, /var/run/utmp ගොනුව ඉවත් කිරීමට යෝජනා කළේය. Glibc හි 2038 ගැටලුව සම්පූර්ණයෙන්ම විසඳීමට බෙදාහැරීම් තුළ. utmp, wtmp සහ lastlog භාවිතා කරන සියලුම යෙදුම් systemd-logind භාවිතා කරන පරිශීලකයින්ගේ ලැයිස්තුවක් ලබා ගැනීමට පරිවර්තනය කිරීමට යෝජිතය.
19 ජනවාරි 2038 වෙනිදා, 32-bit time_t වර්ගය මගින් නිශ්චිතව දක්වා ඇති epochal time counters පිටාර ගලනු ඇත. Glibc, 64-bit time_t වර්ගයක් හඳුන්වා දුන්නද, 32-bit පරිශීලක අවකාශ යෙදුම් සමඟ ගැළපීම පවත්වා ගැනීම සඳහා 64-bit වේදිකාවල සමහර අවස්ථාවලදී 32-bit time_t වර්ගයක් භාවිතා කරයි. එවැනි එක් අවස්ථාවක් වන්නේ දැනට පද්ධතියට ලොග් වී ඇති පරිශීලකයින් පිළිබඳ දත්ත ගබඩා කරන /var/run/utmp ගොනුවයි. utmp හි කාල ක්ෂේත්‍රය 32-bit time_t අගයක් භාවිතයෙන් නියම කර ඇත.
utmp හි කාල ක්ෂේත්‍රය 32-bit සිට 64-bit වර්ගයකට ප්‍රතිස්ථාපනය කිරීම ක්‍රියා නොකරනු ඇත, මෙය Glibc ABI හි වෙනසක් ඇති කිරීමට හේතු වනු ඇත (login(), getutid() සහ utmpname වැනි ශ්‍රිතවල වර්ගය වෙනස් වේ. ()) සහ w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm display managers, emacs, openssh, qemu, samba, rsyslog යනාදිය ඇතුළුව utmp භාවිතා කරන යෙදුම් සමඟ ගැළපීම බිඳ දැමීම. සිදුවිය හැකි අන්තරායන් සහ සංකීර්ණත්වය නිසා, utmp හි time_t වර්ගය ප්‍රතිස්ථාපනය කිරීමේ අදහස Glibc සංවර්ධකයින් විසින් ප්‍රතික්ෂේප කරන ලදී. එම හේතුව නිසාම, අමතර 64-bit කාල ක්ෂේත්‍රයක් එක් කිරීමට utmp ව්‍යුහයේ පවතින නිදහස් ඉඩ භාවිතා කිරීමේ විකල්පය ඉවත දමන ලදී.
මීට අමතරව, utmp හි ටයිප් බිට් ගැඹුර වෙනස් කිරීම දැනට පවතින අනෙකුත් ගැටළු විසඳන්නේ නැත, මම එය ඉවත් කිරීමට ද කැමතියි. උදාහරණයක් ලෙස, utmp වෙත ලිවීමට විශේෂ අයිතිවාසිකම් අවශ්‍ය වන අතර, ඒ සඳහා ක්‍රියාවලීන්ට අමතර වරප්‍රසාද ලබා දීම අවශ්‍ය වේ. තවත් ගැටළුවක් නම්, utmp ගෘහ නිර්මාණ ශිල්පය මඟින් දේශීය පරිශීලකයින්ට DoS ප්‍රහාර එල්ල කිරීමට ඉඩ ලබා දෙන අතර, ගොනු අගුලු හැසිරවීම හරහා utmp සේවාව කඩාකප්පල් කිරීමට තුඩු දෙයි, එමඟින් utmp හි අන්තර්ගතය පද්ධතියේ සැබෑ තත්වය පිළිබිඹු කරන බවට සහතික විය නොහැක. utmp වෙත ප්‍රවේශය හැසිරවීමට අමතර පසුබිම් ක්‍රියාවලියක් භාවිතා කිරීමට යෝජනා කරන ලදී, නමුත් එවැනි කාර්යයන් සඳහා දැනටමත් systemd-logind ක්‍රියාවලියක් පවතින අතර වෙනත් විශේෂිත ක්‍රියාවලියක් දියත් කිරීම සුදුසු නොවේ (යෙදුම් වලට එකවර හසුරුවන්නන් දෙදෙනෙකුට දත්ත මාරු කිරීමට සිදුවේ).
ඒ අතරම, DoS ප්‍රහාර සමඟ ගැටළුව විසඳන විට පවා, utmp හි අන්තර්ගතය තොරතුරු පමණක් වන අතර යථාර්ථයේ පිළිබිඹුවක් සහතික නොකරයි. උදාහරණයක් ලෙස, විවිධ ඉමුලේටර් සහ ටර්මිනල් මල්ටිප්ලෙක්සර් ඔවුන්ගේ තත්වය වෙනස් ලෙස පිළිබිඹු කරයි - GNOME පර්යන්ත පහක් දියත් කිරීමෙන් එක් පරිශීලකයෙකු utmp හි පිළිබිඹු වන අතර, KDE හි konsole හෝ xterm පර්යන්ත පහක් දියත් කිරීමෙන් හයක් සිදු වේ. තිරයේ සහ tmux හි හැසිරීම් සමානව වෙනස් වේ: පළමු අවස්ථාවේ දී, එක් එක් සැසිය වෙනම පරිශීලකයෙකු ලෙස ගණන් ගනු ලැබේ, දෙවනුව, සියලු සැසි සඳහා එක් පරිශීලකයෙකු පමණක් පිළිබිඹු වේ.
එහි ප්‍රතිඵලයක් ලෙස, සරලම විසඳුම ලෙස, දැනට පවතින විකල්ප systemd-logind සේවාව භාවිතා කිරීමට සියලුම යෙදුම් මාරු කිරීමට යෝජනා කර ඇති අතර, utmp වෙත ප්‍රවේශ වන වත්මන් වැඩසටහන් නොමැති වීමෙන් පසුව, utmp වෙත පටිගත කිරීම නවත්වන්න. wtmp ප්‍රතිස්ථාපනය කිරීම සඳහා, systemd-journald භාවිතා කරන පරිශීලකයින් පිළිබඳ තොරතුරු ලිවීම සහ කියවීම සඳහා මෘදුකාංග අතුරුමුහුණත් සකස් කිරීමට යෝජනා කෙරේ. sd-login.h API භාවිතයෙන් හෝ DBUS හරහා libsystemd හරහා utmp ප්‍රතිස්ථාපන දත්ත සැපයීමට අවශ්‍ය ක්‍රියාකාරීත්වය systemd 254 හි මීළඟ නිකුතුව සඳහා වන කේත පදනමට දැනටමත් ඇතුළත් වේ.
මූලාශ්රය: opennet.ru