ສະເຫນີໃຫ້ຢຸດເຊົາການນໍາໃຊ້ utmp ເພື່ອກໍາຈັດ Glibc ຂອງບັນຫາ Y2038

Thorsten Kukuk, ຜູ້ນໍາຂອງທີມງານເຕັກໂນໂລຢີໃນອະນາຄົດທີ່ SUSE (ທີມງານເຕັກໂນໂລຢີໃນອະນາຄົດ, ພັດທະນາ openSUSE MicroOS ແລະ SLE Micro), ຜູ້ທີ່ເຄີຍນໍາພາໂຄງການ SUSE LINUX Enterprise Server ສໍາລັບ 10 ປີ, ແນະນໍາໃຫ້ກໍາຈັດໄຟລ໌ /var/run/utmp ໃນ ການແຈກຢາຍເພື່ອແກ້ໄຂບັນຫາ Y2038 ຢ່າງສົມບູນໃນ Glibc. ທຸກໆແອັບພລິເຄຊັນທີ່ໃຊ້ utmp, wtmp, ແລະ lastlog ໄດ້ຖືກສະເຫນີໃຫ້ຍ້າຍໄປຮັບລາຍຊື່ຜູ້ໃຊ້ທີ່ໃຊ້ systemd-logind.

ໃນວັນທີ 19 ມັງກອນ 2038, ຕົວນັບເວລາ epoch ທີ່ລະບຸໂດຍປະເພດ time_t 32-bit ຈະລົ້ນ. ໃນ Glibc, ເຖິງວ່າຈະມີການນໍາສະເຫນີປະເພດ time_t 64-bit, ເພື່ອຮັກສາຄວາມເຂົ້າກັນໄດ້ກັບຄໍາຮ້ອງສະຫມັກພື້ນທີ່ຜູ້ໃຊ້ 32-bit, ປະເພດ 64-bit time_t ຍັງຖືກນໍາໃຊ້ໃນບາງກໍລະນີໃນເວທີ 32-bit. ຫນຶ່ງກໍລະນີດັ່ງກ່າວແມ່ນໄຟລ໌ /var/run/utmp, ເຊິ່ງເກັບຮັກສາຂໍ້ມູນກ່ຽວກັບຜູ້ໃຊ້ທີ່ເຂົ້າສູ່ລະບົບໃນປັດຈຸບັນ. ຊ່ອງເວລາໃນ utmp ຖືກຕັ້ງໂດຍໃຊ້ຄ່າ time_t 32-bit.

ພຽງແຕ່ປ່ຽນພາກສະຫນາມໃນ utmp ໃນໄລຍະເວລາຈາກ 32-bit ໄປເປັນປະເພດ 64-bit ຈະບໍ່ເຮັດວຽກ, ເພາະວ່ານີ້ຈະປ່ຽນ Glibc ABI (ປະເພດຈະປ່ຽນແປງໃນຫນ້າທີ່ເຊັ່ນ: login(), getutid() ແລະ utmpname()) ແລະທໍາລາຍຄວາມເຂົ້າກັນໄດ້ກັບແອັບພລິເຄຊັນທີ່ໃຊ້ utmp, ລວມທັງ w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm display managers, emacs, openssh, qemu, samba, rsyslog, ແລະອື່ນໆ. ເນື່ອງຈາກຄວາມອຸດົມສົມບູນຂອງ pitfalls ທີ່ເປັນໄປໄດ້ແລະ laboriousness, ຄວາມຄິດຂອງການທົດແທນຄວາມຍາວ bit ຂອງປະເພດ time_t ໃນ utmp ໄດ້ຖືກປະຕິເສດໂດຍນັກພັດທະນາຂອງ Glibc. ສໍາລັບເຫດຜົນດຽວກັນ, ທາງເລືອກທີ່ຈະໃຊ້ພື້ນທີ່ທີ່ມີຢູ່ໃນໂຄງສ້າງ utmp ເພື່ອເພີ່ມຊ່ອງເວລາ 64-bit ເພີ່ມເຕີມໄດ້ຖືກຫຼຸດລົງ.

ນອກຈາກນັ້ນ, ການປ່ຽນແປງຄວາມເລິກບິດຂອງປະເພດໃນ utmp ບໍ່ໄດ້ແກ້ໄຂບັນຫາທີ່ມີຢູ່ແລ້ວອື່ນໆ, ເຊິ່ງຂ້ອຍກໍ່ຢາກຈະກໍາຈັດ. ຕົວຢ່າງ, ການຂຽນໄປຫາ utmp ຮຽກຮ້ອງໃຫ້ມີການອະນຸຍາດພິເສດ, ເຊິ່ງຕ້ອງການສິດທິພິເສດເພີ່ມເຕີມເພື່ອໃຫ້ຂະບວນການຕ່າງໆ. ບັນຫາອີກປະການຫນຶ່ງແມ່ນວ່າສະຖາປັດຕະຍະກໍາ utmp ອະນຸຍາດໃຫ້ຜູ້ໃຊ້ທ້ອງຖິ່ນປະຕິບັດການໂຈມຕີ DoS ທີ່ທໍາລາຍການບໍລິການ utmp ໂດຍຜ່ານການຫມູນໃຊ້ການລັອກໄຟລ໌, ເຮັດໃຫ້ມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະແນ່ໃຈວ່າເນື້ອໃນຂອງ utmp ສະທ້ອນໃຫ້ເຫັນເຖິງສະພາບທີ່ແທ້ຈິງໃນລະບົບ. ມັນໄດ້ຖືກສະເຫນີໃຫ້ໃຊ້ຂະບວນການພື້ນຫລັງເພີ່ມເຕີມເພື່ອຈັດການການເຂົ້າເຖິງ utmp, ແຕ່ສໍາລັບວຽກງານດັ່ງກ່າວມີຂະບວນການເຂົ້າລະບົບແລ້ວແລະການເລີ່ມຕົ້ນຂະບວນການພິເສດອື່ນແມ່ນບໍ່ສົມຄວນ (ແອັບພລິເຄຊັນຈະຕ້ອງໂອນຂໍ້ມູນໃຫ້ສອງຕົວຈັດການໃນເວລາດຽວກັນ) .

ໃນຂະນະດຽວກັນ, ເຖິງແມ່ນວ່າການແກ້ໄຂບັນຫາທີ່ມີການໂຈມຕີ DoS, ເນື້ອໃນຂອງ utmp ຍັງຄົງເປັນຂໍ້ມູນເທົ່ານັ້ນ, ບໍ່ໄດ້ຮັບປະກັນການສະທ້ອນເຖິງຄວາມເປັນຈິງ. ຕົວຢ່າງເຊັ່ນ, ຕົວຈໍາລອງ terminal ທີ່ແຕກຕ່າງກັນແລະ multiplexers ສະທ້ອນໃຫ້ເຫັນສະຖານະຂອງພວກເຂົາແຕກຕ່າງກັນ - ແລ່ນຫ້າ GNOME terminals ຈະເຮັດໃຫ້ຜູ້ໃຊ້ຫນຶ່ງຖືກສະທ້ອນໃຫ້ເຫັນໃນ utmp, ໃນຂະນະທີ່ແລ່ນຫ້າ konsole ຫຼື xterm terminals ໃນ KDE ຈະສົ່ງຜົນໃຫ້ຫົກ. ເຊັ່ນດຽວກັນ, ພຶດຕິກໍາຂອງຫນ້າຈໍແລະ tmux ແຕກຕ່າງກັນ, ໃນກໍລະນີທໍາອິດ, ແຕ່ລະກອງປະຊຸມຖືກນັບເປັນຜູ້ໃຊ້ແຍກຕ່າງຫາກ, ແລະໃນຄັ້ງທີສອງມີພຽງແຕ່ຜູ້ໃຊ້ດຽວເທົ່ານັ້ນທີ່ສະທ້ອນໃຫ້ເຫັນສໍາລັບກອງປະຊຸມທັງຫມົດ.

ດັ່ງນັ້ນ, ເປັນການແກ້ໄຂທີ່ງ່າຍດາຍທີ່ສຸດ, ມັນຖືກສະເຫນີໃຫ້ໂອນທຸກແອັບພລິເຄຊັນເພື່ອໃຊ້ບໍລິການ systemd-logind ທາງເລືອກທີ່ມີຢູ່ແລ້ວແລະ, ຫຼັງຈາກບໍ່ມີໂປຼແກຼມຕົວຈິງທີ່ເຂົ້າເຖິງ utmp, ຢຸດການຂຽນໄປຫາ utmp. ເພື່ອທົດແທນ wtmp, ມັນໄດ້ຖືກສະເຫນີໃຫ້ກະກຽມ APIs ສໍາລັບການຂຽນແລະການອ່ານຂໍ້ມູນກ່ຽວກັບຜູ້ໃຊ້ທີ່ໃຊ້ systemd-journald. codebase ສໍາລັບການປ່ອຍຕໍ່ໄປຂອງ systemd 254 ແລ້ວປະກອບມີຫນ້າທີ່ທີ່ຈໍາເປັນເພື່ອສະຫນອງການທົດແທນຂໍ້ມູນ utmp ຜ່ານ libsystemd ໂດຍໃຊ້ sd-login.h API ຫຼືຜ່ານ DBUS.

ແຫຼ່ງຂໍ້ມູນ: opennet.ru