Thorsten Kukuk หัวหน้าทีม Future Technology Team ของ SUSE (ผู้พัฒนา openSUSE MicroOS และ SLE Micro) ซึ่งเคยเป็นผู้นำโครงการ SUSE Linux Enterprise Server มานาน 10 ปี ได้เสนอให้ลบไฟล์ /var/run/utmp ออกจากดิสทริบิวชันเพื่อแก้ไขปัญหา Glibc Year 2038 อย่างสมบูรณ์ แอปพลิเคชันทั้งหมดที่ใช้ utmp, wtmp และ lastlog ได้รับการเสนอให้ย้ายไปยังการดึงรายชื่อผู้ใช้โดยใช้ systemd-logind
ในวันที่ 19 มกราคม 2038 ตัวนับเวลา epochal ที่กำหนดโดยประเภท time_t 32 บิตจะล้น แม้จะมีการนำประเภท time_t 64 บิตมาใช้ แต่ไลบรารี Glibc ยังคงใช้ประเภท time_t 32 บิตในบางกรณีบนแพลตฟอร์ม 64 บิตเพื่อรักษาความเข้ากันได้กับแอปพลิเคชันพื้นที่ผู้ใช้ 32 บิต หนึ่งในกรณีดังกล่าวคือไฟล์ /var/run/utmp ซึ่งเก็บข้อมูลเกี่ยวกับผู้ใช้ที่เข้าสู่ระบบในขณะนั้น ฟิลด์เวลาใน utmp ถูกระบุโดยใช้ค่า time_t 32 บิต
การแทนที่ฟิลด์เวลา 32 บิตใน utmp ด้วยชนิดข้อมูล 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 เสนอให้สร้าง API สำหรับการเขียนและอ่านข้อมูลผู้ใช้โดยใช้ systemd-journald ฐานโค้ดสำหรับ systemd 254 รุ่นถัดไปมีฟังก์ชันที่จำเป็นสำหรับการจัดเตรียมข้อมูล utmp ทดแทนผ่าน libsystemd โดยใช้ sd-login.h API หรือผ่าน DBUS อยู่แล้ว
ที่มา: opennet.ru
