SUSE မှ Future Technology Team ၏ ခေါင်းဆောင် Thorsten Kukuk သည် SUSE LINUX Enterprise Server ပရောဂျက်ကို 10 နှစ်ကြာ ဦးဆောင်ခဲ့သော openSUSE MicroOS နှင့် SLE Micro ကို တီထွင်ခဲ့ပြီး /var/run/utmp ဖိုင်ကို ဖယ်ရှားရန် အကြံပြုခဲ့သည်။ Glibc ရှိ Y2038 ပြဿနာကို အပြည့်အဝဖြေရှင်းရန် ဖြန့်ဖြူးမှုများ။ utmp၊ wtmp နှင့် lastlog တို့ကို အသုံးပြုသည့် အပလီကေးရှင်းများအားလုံးသည် systemd-logind ကို အသုံးပြု၍ အသုံးပြုသူများစာရင်းကို ရယူရန် အဆိုပြုထားသည်။
ဇန်နဝါရီ 19 ရက်၊ 2038 တွင်၊ 32-bit time_t အမျိုးအစားမှ သတ်မှတ်ထားသော ခေတ်အချိန်ကောင်တာများ ပြည့်လျှံနေမည်ဖြစ်သည်။ Glibc တွင် 64-bit time_t အမျိုးအစားကို မိတ်ဆက်ခဲ့သော်လည်း 32-bit အသုံးပြုသူ-အာကာသအက်ပ်လီကေးရှင်းများနှင့် လိုက်ဖက်ညီမှုရှိစေရန်အတွက် 64-bit time_t အမျိုးအစားကို 32-bit ပလပ်ဖောင်းများတွင် အချို့သောကိစ္စရပ်များတွင် ဆက်လက်အသုံးပြုဆဲဖြစ်သည်။ ထိုသို့သော ကိစ္စရပ်တစ်ခုမှာ စနစ်ထဲသို့ လက်ရှိဝင်ရောက်နေသော သုံးစွဲသူများအကြောင်း အချက်အလက်များကို သိမ်းဆည်းထားသည့် /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 အမျိုးအစား၏ bit length ကို အစားထိုးရန် စိတ်ကူးကို Glibc ၏ developer များက ပယ်ချခဲ့သည်။ တူညီသောအကြောင်းပြချက်ကြောင့် 64-ဘစ်အချိန်အကွက်ကို ထပ်ထည့်ရန် utmp ဖွဲ့စည်းပုံရှိ ရနိုင်သောနေရာများကို အသုံးပြုရန် ရွေးချယ်ခွင့်ကို ပြုတ်ကျခဲ့သည်။
ထို့အပြင်၊ utmp တွင် အမျိုးအစား၏ bit depth ကိုပြောင်းလဲခြင်းသည် အခြားရှိပြီးသားပြဿနာများကို ဖြေရှင်းပေးမည်မဟုတ်ပါ၊ ကျွန်ုပ်လည်း ဖယ်ရှားလိုပါသည်။ ဥပမာအားဖြင့်၊ utmp သို့ စာရေးခြင်းသည် အထူးခွင့်ပြုချက်များ လိုအပ်ပြီး လုပ်ငန်းစဉ်များအတွက် ထပ်လောင်းအခွင့်အရေးများ လိုအပ်သည်။ အခြားပြဿနာမှာ utmp ဗိသုကာသည် ပြည်တွင်းအသုံးပြုသူများအား ဖိုင်သော့ခတ်မှုများကို ကိုင်တွယ်ခြင်းမှတစ်ဆင့် utmp ဝန်ဆောင်မှုကို ချိုးဖျက်သည့် DoS တိုက်ခိုက်မှုများကို လုပ်ဆောင်နိုင်စေကာ၊ utmp ၏ အကြောင်းအရာများသည် စနစ်အတွင်းရှိ စစ်မှန်သောအခြေအနေကို ရောင်ပြန်ဟပ်ရန် မဖြစ်နိုင်ကြောင်း သေချာစေသည်။ utmp သို့ဝင်ရောက်ခွင့်ကိုကိုင်တွယ်ရန်နောက်ထပ်နောက်ခံလုပ်ငန်းစဉ်ကိုအသုံးပြုရန်အဆိုပြုထားသော်လည်းထိုကဲ့သို့သောအလုပ်များအတွက် systemd-logind လုပ်ငန်းစဉ်တစ်ခုရှိနေပြီဖြစ်ပြီးအခြားအထူးပြုလုပ်ငန်းစဉ်ကိုစတင်ရန်အကြံပြုလိုသည်မဟုတ်ပါ (အပလီကေးရှင်းများသည်တစ်ချိန်တည်းတွင်ကိုင်တွယ်သူနှစ်ဦးထံဒေတာလွှဲပြောင်းရပါမည်) .
တစ်ချိန်တည်းမှာပင်၊ DoS တိုက်ခိုက်မှုများနှင့် ပြဿနာကို ဖြေရှင်းသည့်အခါတွင်ပင်၊ utmp ၏ အကြောင်းအရာသည် အဖြစ်မှန်၏ ထင်ဟပ်မှုကို အာမခံချက်မပေးဘဲ သတင်းအချက်အလက်အတွက်သာ ကျန်ရှိတော့သည်။ ဥပမာအားဖြင့်၊ မတူညီသော terminal emulators နှင့် multiplexers များသည် ၎င်းတို့၏ အခြေအနေကို ကွဲပြားစွာ ထင်ဟပ်နေသည် - GNOME terminals ငါးခုသည် အသုံးပြုသူတစ်ဦးကို utmp တွင် ထင်ဟပ်စေမည်ဖြစ်ပြီး KDE တွင် konsole သို့မဟုတ် xterm terminals ငါးခုကို လုပ်ဆောင်နေချိန်တွင် ခြောက်ခုဖြစ်ပေါ်မည်ဖြစ်သည်။ အလားတူ၊ စခရင်နှင့် tmux ၏ အပြုအမူ ကွဲပြားသည်၊ ပထမအခြေအနေတွင် စက်ရှင်တစ်ခုစီကို သီးခြားအသုံးပြုသူအဖြစ် ရေတွက်ပြီး ဒုတိယတွင် စက်ရှင်အားလုံးအတွက် အသုံးပြုသူ တစ်ဦးတည်းကိုသာ ထင်ဟပ်စေသည်။
ရလဒ်အနေဖြင့်၊ အရိုးရှင်းဆုံးဖြေရှင်းချက်အနေဖြင့်၊ ရှိပြီးသားအခြားရွေးချယ်စရာ systemd-logind ဝန်ဆောင်မှုကိုအသုံးပြုရန်အတွက် အပလီကေးရှင်းများအားလုံးကို လွှဲပြောင်းရန် အဆိုပြုထားပြီး၊ utmp ကိုဝင်ရောက်ကြည့်ရှုသည့် အမှန်တကယ်ပရိုဂရမ်များမရှိပါက၊ utmp သို့ စာရေးခြင်းကို ရပ်လိုက်ပါ။ wtmp ကို အစားထိုးရန်အတွက် systemd-journald ကို အသုံးပြု၍ သုံးစွဲသူများအကြောင်း အချက်အလက် ရေးသားခြင်းနှင့် ဖတ်ခြင်းအတွက် APIs ကို ပြင်ဆင်ရန် အဆိုပြုထားသည်။ လာမည့် systemd 254 ၏နောက်ထွက်ရှိမှုအတွက် codebase တွင် sd-login.h API သို့မဟုတ် DBUS မှတစ်ဆင့် libsystemd မှတစ်ဆင့် အစားထိုး utmp ဒေတာကို ပေးဆောင်ရန် လိုအပ်သောလုပ်ဆောင်ချက်များ ပါဝင်ပြီးဖြစ်သည်။
source: opennet.ru