Для избавления Glibc от проблемы 2038 года предложено прекратить использование utmp

Торстен Кукук (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