Торстен Кукук, водач на идната група за развој на технологија во SUSE (Future Technology Team, развива openSUSE MicroOS и SLE Micro), кој претходно го водеше проектот SUSE LINUX Enterprise Server 10 години, предложи да се ослободиме од датотеката /var/run/utmp во дистрибуциите за целосно решавање на проблемот од 2038 година во Глибц. Сите апликации кои користат utmp, wtmp и lastlog се предлагаат да се конвертираат во добивање листа на корисници кои користат systemd-login.
На 19 јануари 2038 година, епохалните бројачи на време специфицирани со 32-битен тип time_t ќе се прелеат. Glibc, и покрај воведувањето на 64-битен тип time_t, продолжува да користи 32-битен тип time_t во некои случаи на 64-битни платформи за да ја одржи компатибилноста со 32-битни апликации за кориснички простор. Еден таков случај е датотеката /var/run/utmp, која складира податоци за корисници кои моментално се најавени во системот. Временското поле во utmp е одредено со 32-битна time_t вредност.
Едноставното заменување на полето за време во utmp од 32-битен на 64-битен тип нема да работи, бидејќи тоа ќе доведе до промена во Glibc ABI (типот ќе се промени во функциите како login(), getutid() и utmpname ()) и прекин на компатибилноста со апликациите што користат utmp, вклучувајќи w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm менаџери за прикажување, emacs, openssh, qemu, samba, rsyslog итн. Поради изобилството на можни замки и сложеност, идејата за замена на типот time_t во utmp беше отфрлена од програмерите на Glibc. Од истата причина, опцијата за користење на достапниот слободен простор во структурата utmp за додавање дополнително 64-битно временско поле беше отфрлена.
Покрај тоа, менувањето на длабочината на битот на типот во utmp не ги решава другите постоечки проблеми, од кои исто така би сакал да се ослободам. На пример, пишувањето на utmp бара посебни права, што бара процесите да добијат дополнителни привилегии. Друг проблем е што utmp архитектурата им овозможува на локалните корисници да вршат DoS напади, што доведува до нарушување на услугата utmp преку манипулација со заклучување на датотеки, што го прави невозможно да се биде сигурен дека содржината на utmp ја одразува вистинската состојба во системот. Беше предложено да се користи дополнителен процес во заднина за да се справи со пристапот до utmp, но за такви задачи веќе постои процес на системско најавување и не е препорачливо да се започне друг специјализиран процес (апликациите ќе мора да пренесуваат податоци на два ракувачи истовремено).
Во исто време, дури и при решавање на проблемот со DoS нападите, содржината на utmp останува само информативна и не гарантира одраз на реалноста. На пример, различни емулатори и терминални мултиплексери различно ја рефлектираат нивната состојба - лансирањето пет терминали на GNOME ќе резултира со тоа што еден корисник ќе се рефлектира во utmp, а лансирањето на пет конзоли или xterm терминали во KDE ќе резултира со шест. Однесувањето на екранот и tmux е слично различно: во првиот случај, секоја сесија се брои како посебен корисник, а во вториот, само еден корисник се рефлектира за сите сесии.
Како резултат на тоа, како наједноставно решение, се предлага да се префрлат сите апликации за користење на веќе постоечката алтернативна услуга systemd-logind и, откако нема тековни програми кои пристапуваат до utmp, да престане да снима во utmp. За да се замени wtmp, се предлага да се подготват софтверски интерфејси за пишување и читање информации за корисници кои користат systemd-journald. Базата на кодови за следното издание на systemd 254 веќе ја вклучува потребната функционалност за да се обезбедат податоци за замена на utmp преку libsystemd со користење на sd-login.h API или преку DBUS.
Извор: opennet.ru