Торстен Кукук, ръководител на екипа за бъдещи технологии в SUSE (Екипът за бъдещи технологии, разработва 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 (типът ще се промени във функции като 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 остава само информационно, без да гарантира отражение на реалността. Например, различни терминални емулатори и мултиплексори отразяват състоянието си по различен начин - стартирането на пет терминала на GNOME ще доведе до отразяване на един потребител в utmp, докато стартирането на пет конзолни или xterm терминала в KDE ще доведе до шест. По подобен начин поведението на screen и tmux се различава, в първия случай всяка сесия се брои като отделен потребител, а във втория само един потребител се отразява за всички сесии.
В резултат на това, като най-просто решение, се предлага да се прехвърлят всички приложения, за да използват вече съществуващата алтернативна услуга systemd-logind и след като няма реални програми, които имат достъп до utmp, да се спре писането в utmp. За да се замени wtmp, се предлага да се подготвят API за писане и четене на информация за потребители, използващи systemd-journald. Кодовата база за следващото издание на systemd 254 вече включва необходимите функции за предоставяне на заместващи utmp данни чрез libsystemd, използвайки sd-login.h API или чрез DBUS.
Източник: opennet.ru