تورستن کوکوک، رهبر گروه توسعه فناوری آینده در SUSE (تیم فناوری آینده، توسعه دهنده openSUSE MicroOS و SLE Micro)، که قبلاً پروژه SUSE LINUX Enterprise Server را به مدت 10 سال رهبری می کرد، پیشنهاد کرد که از شر فایل /var/run/utmp خلاص شوید. در توزیع‌ها برای رفع کامل مشکل 2038 در Glibc. همه برنامه‌هایی که از utmp، wtmp و lastlog استفاده می‌کنند، پیشنهاد می‌شود تا به لیستی از کاربران با استفاده از systemd-login تبدیل شوند.
در 19 ژانویه 2038، شمارشگرهای زمان دوره ای مشخص شده توسط نوع 32 بیتی time_t سرریز خواهند شد. Glibc، با وجود معرفی نوع 64 بیتی time_t، در برخی موارد از نوع 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 و غیره. به دلیل فراوانی مشکلات احتمالی و پیچیدگی، ایده جایگزینی نوع time_t در utmp توسط توسعه دهندگان Glibc رد شد. به همین دلیل، گزینه استفاده از فضای آزاد موجود در ساختار utmp برای افزودن یک فیلد زمانی 64 بیتی اضافی کنار گذاشته شد.
علاوه بر این، تغییر عمق بیت نوع در utmp مشکلات دیگر موجود را حل نمی کند، که من نیز می خواهم از شر آنها خلاص شوم. برای مثال، نوشتن در utmp به حقوق خاصی نیاز دارد، که مستلزم اعطای امتیازات اضافی به فرآیندها است. مشکل دیگر این است که معماری utmp به کاربران محلی اجازه می دهد تا حملات DoS را انجام دهند، که منجر به اختلال در سرویس utmp از طریق دستکاری قفل فایل ها می شود، که باعث می شود اطمینان حاصل شود که محتوای utmp منعکس کننده وضعیت واقعی در سیستم است. پیشنهاد شده بود از یک فرآیند پس‌زمینه اضافی برای مدیریت دسترسی به utmp استفاده شود، اما برای چنین کارهایی از قبل یک فرآیند systemd-logind وجود دارد و راه‌اندازی فرآیند تخصصی دیگری توصیه نمی‌شود (برنامه‌ها باید داده‌ها را به طور همزمان به دو هندلر منتقل کنند).
در عین حال، حتی هنگام حل مشکل حملات DoS، محتوای utmp فقط اطلاعاتی باقی می ماند و بازتاب واقعیت را تضمین نمی کند. به عنوان مثال، شبیه سازهای مختلف و مالتی پلکسرهای ترمینال وضعیت خود را به طور متفاوتی منعکس می کنند - راه اندازی پنج پایانه گنوم منجر به منعکس شدن یک کاربر در utmp می شود و راه اندازی پنج پایانه konsole یا xterm در KDE منجر به شش می شود. رفتار screen و tmux به طور مشابه متفاوت است: در حالت اول، هر جلسه به عنوان یک کاربر جداگانه محاسبه می شود و در حالت دوم، تنها یک کاربر برای همه جلسات منعکس می شود.
در نتیجه، به عنوان ساده‌ترین راه‌حل، پیشنهاد می‌شود همه برنامه‌ها را برای استفاده از سرویس جایگزین موجود systemd-logind منتقل کنید و پس از اینکه برنامه‌های فعلی به utmp دسترسی نداشتند، ضبط را به utmp متوقف کنید. برای جایگزینی wtmp، پیشنهاد شده است که رابط های نرم افزاری برای نوشتن و خواندن اطلاعات مربوط به کاربران با استفاده از systemd-journald آماده شود. پایگاه کد برای نسخه بعدی systemd 254 از قبل شامل عملکردهای لازم برای ارائه داده های جایگزین utmp از طریق libsystemd با استفاده از sd-login.h API یا از طریق DBUS است.
منبع: opennet.ru