В SUSE предлагают прекратить использование utmp для решения проблемы Y2038 в Glibc.

Y2038

Проблема 2038 года может привести к сбою части программного обеспечения в этом году. Проблема затрагивает программы, использующие представление времени на основе POSIX.

Торстен Кукук, лидер группы от SUSE Future Technology (Future Technology Team, разрабатывает openSUSE MicroOS и SLE Micr), ранее руководивший проектом 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-битными приложениями пользовательского пространства 32-битный тип time_t все еще используется в некоторых случаях на 64-битных платформах.

Есть две основные проблемы с utmp/utmpx с glibc, например, на x86-64:

32-битное поле time_t используется для времени, которое переполнится в 2038 году.
Существуют проблемы с дизайном, которые допускают DoS-атаку (блокировка utmp/wtmp позволяет непривилегированному пользователю отказать в обслуживании)
Анализ второй проблемы разработчиками glibc показал, что для обработки доступа utmp/utmpx потребуется дополнительный демон.

Хотя есть и другие проблемы...

Одним из таких случаев является файл /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 и т. д.

Из-за обилия потенциальных подводных камней и трудолюбия, разработчики Glibc отказался от идеи замены разрядности типа time_t в utmp. По той же причине удалена возможность использовать доступное пространство в структуре 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 предлагается подготовить API для записи и чтения информации о пользователях с помощью systemd-journald.

Наконец, стоит упомянуть, что кодовая база для следующей версии systemd 254 уже включает в себя необходимые функции предоставить замену данных utmp через libsystemd с помощью API sd-login.ho через DBUS.

Если вы хотите узнать больше об этом, вы можете ознакомиться с деталями По следующей ссылке.


Оставьте свой комментарий

Ваш электронный адрес не будет опубликован. Обязательные для заполнения поля помечены *

*

*

  1. Ответственный за данные: AB Internet Networks 2008 SL
  2. Назначение данных: контроль спама, управление комментариями.
  3. Легитимация: ваше согласие
  4. Передача данных: данные не будут переданы третьим лицам, кроме как по закону.
  5. Хранение данных: база данных, размещенная в Occentus Networks (ЕС)
  6. Права: в любое время вы можете ограничить, восстановить и удалить свою информацию.