تورستن کوکوک، رهبر تیم فناوری آینده در SUSE (توسعهدهنده openSUSE MicroOS و SLE Micro)، که پیش از این به مدت ۱۰ سال پروژه SUSE Linux Enterprise Server را رهبری میکرد، پیشنهاد داد که فایل /var/run/utmp از توزیعها حذف شود تا مشکل Glibc Year 2038 به طور کامل حل شود. پیشنهاد میشود که تمام برنامههایی که از utmp، wtmp و lastlog استفاده میکنند، به سیستم بازیابی لیست کاربران با استفاده از systemd-logind منتقل شوند.
در ۱۹ ژانویه ۲۰۳۸، شمارندههای زمان دورهای مشخص شده توسط نوع ۳۲ بیتی time_t سرریز خواهند شد. با وجود معرفی نوع ۶۴ بیتی time_t، کتابخانه Glibc همچنان در برخی موارد در پلتفرمهای ۶۴ بیتی از نوع ۳۲ بیتی time_t استفاده میکند تا سازگاری با برنامههای فضای کاربری ۳۲ بیتی را حفظ کند. یکی از این موارد، فایل /var/run/utmp است که دادههای مربوط به کاربرانی را که در حال حاضر به سیستم وارد شدهاند، ذخیره میکند. فیلد زمان در utmp با استفاده از مقدار ۳۲ بیتی time_t مشخص میشود.
جایگزینی فیلد زمان ۳۲ بیتی در utmp با یک نوع ۶۴ بیتی به سادگی امکانپذیر نیست، زیرا این کار ABI مربوط به Glibc را تغییر میدهد (نوع توابعی مانند login()، getutid() و utmpname() تغییر میکند) و سازگاری با برنامههایی که از utmp استفاده میکنند، از جمله w، who، uptime، login، su، sudo، useradd، systemd، sysvinit، tcsh، xterm display managerها، emacs، openssh، qemu، samba، rsyslog و موارد دیگر را از بین میبرد. به دلیل مشکلات احتمالی فراوان و پیچیدگیهای موجود، ایده جایگزینی نوع time_t در utmp توسط توسعهدهندگان Glibc رد شد. به همین دلیل، گزینه استفاده از فضای خالی موجود در ساختار utmp برای اضافه کردن یک فیلد زمان ۶۴ بیتی اضافی نیز رد شد.
علاوه بر این، تغییر عمق بیت نوع فایل 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 با استفاده از API sd-login.h یا از طریق DBUS است.
منبع: opennet.ru
