Glibc-ning Y2038 muammosidan xalos bo'lish uchun utmp-dan foydalanishni to'xtatish taklif qilindi

Ilgari SUSE LINUX Enterprise Server loyihasini 10 yil davomida boshqargan SUSE (Future Technology Team, openSUSE MicroOS va SLE Micro-ni ishlab chiqadi) Kelajakdagi Texnologiyalar jamoasi rahbari Torsten Kukuk /var/run/utmp faylidan xalos bo'lishni taklif qildi. Glibc-dagi Y2038 muammosini to'liq hal qilish uchun tarqatish. Utmp, wtmp va lastlog-dan foydalanadigan barcha ilovalarni systemd-logind-dan foydalanadigan foydalanuvchilar ro'yxatini olish uchun ko'chirish taklif etiladi.

19-yil 2038-yanvarda 32-bitli time_t turi bilan belgilangan davr vaqti hisoblagichlari toβ€˜lib-toshib ketadi. Glibc-da, 64-bitli time_t turi joriy qilinganiga qaramay, 32-bitli foydalanuvchi-kosmik ilovalar bilan moslikni saqlash uchun, 64-bitli time_t turi hali ham 32-bitli platformalarda ba'zi hollarda qo'llaniladi. Bunday holatlardan biri /var/run/utmp fayli bo'lib, u hozirda tizimga kirgan foydalanuvchilar haqidagi ma'lumotlarni saqlaydi. Utmp-dagi vaqt maydoni 32-bit time_t qiymati yordamida o'rnatiladi.

Vaqt o'tishi bilan utmp-dagi maydonni 32-bitli turdan 64-bitli turga o'zgartirish ishlamaydi, chunki bu Glibc ABI-ni o'zgartiradi (tur login(), getutid() va utmpname() kabi funktsiyalarda o'zgaradi. ) va utmp-dan foydalanadigan ilovalar bilan muvofiqlikni buzish, jumladan w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm displey menejerlari, emacs, openssh, qemu, samba, rsyslog va boshqalar. Mumkin bo'lgan tuzoqlarning ko'pligi va mashaqqatlilik tufayli utmp-da time_t turining bit uzunligini almashtirish g'oyasi Glibc ishlab chiquvchilari tomonidan rad etildi. Xuddi shu sababga ko'ra, qo'shimcha 64 bitli vaqt maydonini qo'shish uchun utmp tuzilmasidagi mavjud bo'sh joydan foydalanish imkoniyati bekor qilindi.

Bundan tashqari, utmp-da turning bit chuqurligini o'zgartirish boshqa mavjud muammolarni hal qilmaydi, men bundan xalos bo'lishni xohlayman. Masalan, utmp ga yozish uchun maxsus ruxsatlar talab qilinadi, bu jarayonlarga qo'shimcha imtiyozlar berilishini talab qiladi. Yana bir muammo shundaki, utmp arxitekturasi mahalliy foydalanuvchilarga fayl blokirovkalarini manipulyatsiya qilish orqali utmp xizmatini buzadigan DoS hujumlarini amalga oshirish imkonini beradi, bu esa utmp tarkibi tizimdagi haqiqiy holatni aks ettirishiga ishonch hosil qilishni imkonsiz qiladi. Utmp-ga kirishni boshqarish uchun qo'shimcha fon jarayonidan foydalanish taklif qilindi, ammo bunday vazifalar uchun tizimga kirish jarayoni allaqachon mavjud va boshqa maxsus jarayonni boshlash tavsiya etilmaydi (ilovalar bir vaqtning o'zida ikkita ishlov beruvchiga ma'lumotlarni uzatishi kerak). .

Shu bilan birga, DoS hujumlari bilan bog'liq muammoni hal qilishda ham, utmp mazmuni faqat ma'lumot bo'lib qoladi va haqiqatning aksini kafolatlamaydi. Misol uchun, turli terminal emulyatorlari va multipleksorlari ularning holatini boshqacha aks ettiradi - beshta GNOME terminalini ishga tushirish bitta foydalanuvchining utmp da aks ettirilishiga olib keladi, KDEda beshta konsole yoki xterm terminalini ishlatish esa oltitaga olib keladi. Xuddi shunday, ekran va tmux ning xatti-harakatlari farqlanadi, birinchi holatda har bir seans alohida foydalanuvchi sifatida hisoblanadi, ikkinchisida esa barcha seanslar uchun faqat bitta foydalanuvchi aks ettiriladi.

Natijada, eng oddiy yechim sifatida, barcha ilovalarni allaqachon mavjud bo'lgan tizimd-logind muqobil xizmatidan foydalanishga o'tkazish va utmp-ga kirish uchun haqiqiy dasturlar mavjud bo'lmagandan so'ng, utmp-ga yozishni to'xtatish taklif etiladi. Wtmp o'rnini bosish uchun systemd-journald-dan foydalanuvchi foydalanuvchilar haqidagi ma'lumotlarni yozish va o'qish uchun API-larni tayyorlash taklif etiladi. Systemd 254 ning keyingi versiyasi uchun kodlar bazasi allaqachon sd-login.h API yoki DBUS orqali libsystemd orqali utmp ma'lumotlarini almashtirishni ta'minlash uchun zarur funktsiyalarni o'z ichiga oladi.

Manba: opennet.ru

a Izoh qo'shish