Торстен Кукук (Thorsten Kukuk), лідер групи з розвитку технологій майбутнього в компанії SUSE (Future Technology Team, розвиває openSUSE MicroOS і SLE Micro), який раніше 10 років керував проектом SUSE LINUX Enterprise Server, запропонував позбавитися файлу /var/run/utmp в дистрибутиви для повного вирішення проблеми 2038 року в Glibc. Всі програми, що використовують utmp, wtmp та lastlog, пропонується перевести на отримання списку користувачів за допомогою systemd-logind.
19 січня 2038 відбудеться переповнення лічильників епохального часу, заданих 32-розрядним типом time_t. У бібліотеці Glibc, незважаючи на впровадження 64-розрядного типу time_t, для збереження сумісності з 32-розрядними програмами простору користувача в деяких випадках на 64-розрядних платформах продовжує застосовуватися 32-розрядний тип time_t. Одним з таких випадків є файл /var/run/utmp, який зберігає дані про користувачів, які зараз працюють у системі. Поле з часом utmp задається з використанням 32-розрядного значення time_t.
Просто замінити поле з часом в utmp з 32-розрядного на 64-розрядний тип не вийде, оскільки це призведе до зміни ABI Glibc (зміниться тип у функціях, подібних до login(), getutid() і utmpname()) і порушення сумісності з додатками, що використовують utmp, серед яких w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm дисплейні менеджери, emacs, openssh, qemu, samba, rsyslog і т.п. Через велику кількість можливих підводних каменів і трудомісткості ідея заміни в utmp розрядності типу time_t була відкинута розробниками Glibc. З тієї ж причини був відкинутий варіант з використанням вільного простору, що є в структурі utmp, для додавання додаткового 64-розрядного поля для часу.
Крім того, зміна розрядності типу в utmp не вирішує інші наявні проблеми, яких також хотілося б позбутися. Наприклад, для запису в utmp потрібні спеціальні права, що вимагає надання додаткових привілеїв. Ще одна проблема пов'язана з тим, що архітектура utmp допускає здійснення локальними користувачами DoS-атак, що призводять до порушення роботи сервісу utmp через маніпуляції з блокуваннями на файл, через що не можна бути впевненим, що utmp відображає реальний стан в системі. Для обробки доступу до utmp пропонувалося використовувати додатковий фоновий процес, але для подібних завдань вже існує процес systemd-logind і запуск ще одного спеціалізованого процесу не є доцільним (додаткам доведеться передавати дані одночасно у два обробники).
При цьому навіть при вирішенні проблеми з DoS-атаками вміст utmp залишається лише інформаційним, що не гарантує відображення реальної дійсності. Наприклад, різні емулятори та мультиплексори терміналів по-різному відображають свій стан — запуск п'яти терміналів GNOME призведе до відображення в utmp одного користувача, а запуск п'яти терміналів konsole або xterm у KDE — шести. Аналогічно відрізняється поведінка screen і tmux, у першому випадку кожен сеанс враховується як окремий користувач, тоді як у другому відбивається лише одне користувач попри всі сеанси.
У результаті як найпростіше рішення пропонується перекласти всі додатки на використання вже існуючого альтернативного сервісу systemd-logind і після того, як не залишиться актуальних програм, що звертаються до utmp, припинити запис у utmp. Для заміни wtmp пропонується підготувати програмні інтерфейси для запису та читання інформації про користувачів за допомогою systemd-journald. У кодову базу наступного випуску systemd 254 вже включені необхідні функції для надання utmp даних, що замінюють, через libsystemd з використанням API sd-login.h або через DBUS.
Джерело: opennet.ru