Thorsten Kukuk ผู้นำกลุ่มพัฒนาเทคโนโลยีแห่งอนาคตที่ SUSE (ทีมเทคโนโลยีแห่งอนาคต พัฒนา openSUSE MicroOS และ SLE Micro) ซึ่งก่อนหน้านี้เป็นผู้นำโครงการ SUSE LINUX Enterprise Server มาเป็นเวลา 10 ปี แนะนำให้กำจัดไฟล์ /var/run/utmp ในการแจกแจงเพื่อแก้ไขปัญหาปี 2038 ใน Glibc อย่างสมบูรณ์ แอปพลิเคชันทั้งหมดที่ใช้ utmp, wtmp และ Lastlog ได้รับการเสนอให้แปลงเพื่อรับรายชื่อผู้ใช้ที่ใช้ systemd-logind
ในวันที่ 19 มกราคม 2038 ตัวนับเวลายุคที่ระบุโดยประเภท time_t 32 บิตจะล้น Glibc แม้จะแนะนำประเภท time_t 64 บิต แต่ยังคงใช้ประเภท time_t 32 บิตในบางกรณีบนแพลตฟอร์ม 64 บิต เพื่อรักษาความเข้ากันได้กับแอปพลิเคชันพื้นที่ผู้ใช้ 32 บิต กรณีดังกล่าวคือไฟล์ /var/run/utmp ซึ่งเก็บข้อมูลเกี่ยวกับผู้ใช้ที่ล็อกอินเข้าสู่ระบบในปัจจุบัน ฟิลด์เวลาใน utmp ถูกระบุโดยใช้ค่า time_t 32 บิต
เพียงแทนที่ฟิลด์เวลาใน utmp จากประเภท 32 บิตเป็น 64 บิตจะไม่ทำงาน เนื่องจากจะนำไปสู่การเปลี่ยนแปลงใน Glibc ABI (ประเภทจะเปลี่ยนในฟังก์ชันเช่น Login(), getutid() และ utmpname ()) และทำลายความเข้ากันได้กับแอปพลิเคชันที่ใช้ utmp รวมถึง w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm display managers, emacs, openssh, qemu, samba, rsyslog เป็นต้น เนื่องจากข้อผิดพลาดและความซับซ้อนที่เป็นไปได้มากมาย นักพัฒนา Glibc จึงปฏิเสธแนวคิดในการแทนที่ประเภท time_t ใน utmp ด้วยเหตุผลเดียวกัน ตัวเลือกในการใช้พื้นที่ว่างที่มีอยู่ในโครงสร้าง utmp เพื่อเพิ่มฟิลด์เวลา 64 บิตเพิ่มเติมจึงถูกยกเลิก
นอกจากนี้ การเปลี่ยนความลึกบิตของประเภทใน utmp ไม่สามารถแก้ปัญหาอื่นๆ ที่มีอยู่ได้ ซึ่งฉันอยากจะกำจัดออกไปด้วย ตัวอย่างเช่น การเขียนถึง utmp ต้องใช้สิทธิ์พิเศษ ซึ่งกำหนดให้กระบวนการต้องได้รับสิทธิ์เพิ่มเติม ปัญหาอีกประการหนึ่งคือสถาปัตยกรรม utmp อนุญาตให้ผู้ใช้ภายในทำการโจมตี DoS ซึ่งนำไปสู่การหยุดชะงักของบริการ utmp ผ่านการดัดแปลงการล็อคไฟล์ ซึ่งทำให้เป็นไปไม่ได้ที่จะแน่ใจได้ว่าเนื้อหาของ utmp สะท้อนถึงสถานะที่แท้จริงในระบบ มีการเสนอให้ใช้กระบวนการพื้นหลังเพิ่มเติมเพื่อจัดการการเข้าถึง utmp แต่สำหรับงานดังกล่าวมีกระบวนการ systemd-logind อยู่แล้วและไม่แนะนำให้เปิดตัวกระบวนการพิเศษอื่น (แอปพลิเคชันจะต้องถ่ายโอนข้อมูลไปยังตัวจัดการสองคนพร้อมกัน)
ในเวลาเดียวกัน แม้ว่าจะแก้ไขปัญหาด้วยการโจมตี DoS ก็ตาม เนื้อหาของ utmp ยังคงเป็นเพียงการให้ข้อมูลและไม่รับประกันการสะท้อนของความเป็นจริง ตัวอย่างเช่น โปรแกรมจำลองและเทอร์มินัลมัลติเพล็กเซอร์ที่แตกต่างกันจะสะท้อนสถานะที่แตกต่างกัน - การเปิดเทอร์มินัล GNOME ห้าเทอร์มินัลจะส่งผลให้ผู้ใช้หนึ่งรายถูกสะท้อนเป็น utmp และการเปิดตัวเทอร์มินัล konsole หรือ xterm ห้าเทอร์มินัลใน KDE จะส่งผลให้มีหกเทอร์มินัล ลักษณะการทำงานของ screen และ tmux แตกต่างกันในทำนองเดียวกัน โดยในกรณีแรก แต่ละเซสชันจะนับเป็นผู้ใช้แยกกัน และในกรณีที่สอง จะมีเพียงผู้ใช้รายเดียวเท่านั้นที่สะท้อนให้เห็นสำหรับทุกเซสชัน
ด้วยเหตุนี้ วิธีแก้ปัญหาที่ง่ายที่สุดจึงเสนอให้ถ่ายโอนแอปพลิเคชันทั้งหมดเพื่อใช้บริการ systemd-logind ทางเลือกที่มีอยู่แล้ว และหลังจากไม่มีโปรแกรมปัจจุบันที่เข้าถึง utmp ให้หยุดการบันทึกเป็น utmp หากต้องการแทนที่ wtmp เสนอให้เตรียมอินเทอร์เฟซซอฟต์แวร์สำหรับการเขียนและอ่านข้อมูลเกี่ยวกับผู้ใช้โดยใช้ systemd-journald โค้ดเบสสำหรับ systemd 254 รุ่นถัดไปมีฟังก์ชันการทำงานที่จำเป็นเพื่อให้ข้อมูลการแทนที่ utmp ผ่าน libsystemd โดยใช้ sd-login.h API หรือผ่าน DBUS อยู่แล้ว
ที่มา: opennet.ru