Для избавления 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 API или через DBUS.
Источник: http://www.opennet.ru/opennews/art.shtml? num=58750
© OpenNet
