Thorsten Kukuk ، قائد فريق Future Technology في SUSE (Future Technology Team ، يطور openSUSE MicroOS و SLE Micro) ، الذي قاد سابقًا مشروع SUSE LINUX Enterprise Server لمدة 10 سنوات ، اقترح التخلص من ملف / var / run / utmp في التوزيعات لمعالجة مشكلة Y2038 بالكامل في Glibc. يُقترح نقل جميع التطبيقات التي تستخدم utmp و wtmp و lastlog للحصول على قائمة بالمستخدمين الذين يستخدمون systemd-logind.
في 19 يناير 2038 ، ستتجاوز عدادات وقت الحقبة المحددة بواسطة النوع 32 بت time_t. في Glibc ، على الرغم من إدخال نوع 64 بت time_t ، للحفاظ على التوافق مع تطبيقات مساحة المستخدم 32 بت ، يستمر استخدام النوع 64 بت time_t في بعض الحالات على الأنظمة الأساسية 32 بت. إحدى هذه الحالات هي ملف / var / run / utmp ، الذي يخزن بيانات حول المستخدمين المسجلين حاليًا في النظام. يتم تعيين حقل الوقت في utmp باستخدام قيمة 32 بت time_t.
ببساطة ، لن يعمل تغيير حقل في utmp بمرور الوقت من نوع 32 بت إلى نوع 64 بت ، حيث سيؤدي ذلك إلى تغيير Glibc ABI (سيتغير النوع في وظائف مثل تسجيل الدخول () و getutid () و utmpname ()) وكسر التوافق مع التطبيقات التي تستخدم utmp ، بما في ذلك w ، who ، uptime ، login ، su ، sudo ، useradd ، systemd ، sysvinit ، tcsh ، xterm display manager ، emacs ، openssh ، qemu ، samba ، rsyslog ، إلخ. نظرًا لوفرة المخاطر المحتملة والجهد ، فقد رفض مطورو Glibc فكرة استبدال طول البت لنوع time_t في utmp. للسبب نفسه ، تم إسقاط خيار استخدام المساحة المتاحة في بنية utmp لإضافة حقل وقت إضافي 64 بت.
بالإضافة إلى ذلك ، لا يؤدي تغيير عمق البت للنوع في utmp إلى حل المشكلات الأخرى الموجودة ، والتي أود أيضًا التخلص منها. على سبيل المثال ، تتطلب الكتابة إلى utmp أذونات خاصة ، والتي تتطلب امتيازات إضافية لمنحها للعمليات. مشكلة أخرى هي أن بنية utmp تسمح للمستخدمين المحليين بتنفيذ هجمات DoS التي تعطل خدمة utmp من خلال التلاعب بأقفال الملفات ، مما يجعل من المستحيل التأكد من أن محتويات utmp تعكس الحالة الحقيقية في النظام. تم اقتراح استخدام عملية خلفية إضافية للتعامل مع الوصول إلى utmp ، ولكن لمثل هذه المهام توجد بالفعل عملية systemd-logind ولا يُنصح ببدء عملية متخصصة أخرى (سيتعين على التطبيقات نقل البيانات إلى اثنين من المعالجات في نفس الوقت) .
في الوقت نفسه ، حتى عند حل مشكلة هجمات DoS ، يظل محتوى utmp إعلاميًا فقط ، ولا يضمن انعكاسًا للواقع. على سبيل المثال ، تعكس المحاكيات الطرفية ومضاعفات الإرسال المختلفة حالتها بشكل مختلف - سيؤدي تشغيل خمس محطات جنوم إلى انعكاس مستخدم واحد في utmp ، بينما سيؤدي تشغيل خمس محطات كونسول أو محطات إكسترم في كيدي إلى ستة. وبالمثل ، يختلف سلوك Screen و tmux ، ففي الحالة الأولى يتم احتساب كل جلسة كمستخدم منفصل ، وفي الحالة الثانية ينعكس مستخدم واحد فقط لجميع الجلسات.
نتيجة لذلك ، كأبسط حل ، يُقترح نقل جميع التطبيقات لاستخدام خدمة systemd-logind البديلة الموجودة بالفعل ، وبعد عدم وجود برامج فعلية تصل إلى utmp ، توقف عن الكتابة إلى utmp. لاستبدال wtmp ، يُقترح إعداد واجهات برمجة التطبيقات لكتابة وقراءة المعلومات حول المستخدمين الذين يستخدمون systemd-journalald. تتضمن قاعدة الكود للإصدار التالي من systemd 254 الوظائف الضرورية لتوفير بيانات utmp بديلة عبر libsystemd باستخدام sd-login.h API أو عبر DBUS.
المصدر: opennet.ru