Для избавления Glibc от проблемы 2038 года предложено прекратить использование utmp
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Торстен Кукук (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
===========
Похожие новости
- Главная ссылка к новости (https://www.thkukuk.de/blog/Y2...)
- OpenNews: 14 июля эпохальное время Unix достигнет отметки в полтора миллиарда секунд
- OpenNews: 30 июня при синхронизации времени появится лишняя секунда
- OpenNews: Перевод мировых атомных часов на одну секунду привёл к массовому зависанию серверных приложений
- OpenNews: Решено с 2035 года приостановить синхронизацию мировых атомных часов с астрономическим временем
Похожие новости:
- Выпуск системной библиотеки Glibc 2.37
- Реализована возможность сборки Glibc при помощи инструментария LLVM
- Выпуск системной библиотеки Glibc 2.36
- Выпуск системной библиотеки Glibc 2.35
- Уязвимости в OpenSSL, Glibc, util-linux, драйверах i915 и vmwgfx
- Уязвимось в Glibc, позволяющая вызвать крах чужого процесса
- Выпуск системной библиотеки Glibc 2.34
- Проект Glibc отменил обязательную передачу прав на код Фонду СПО
- Разработчики Glibc рассматривают вопрос прекращения передачи прав на код Фонду СПО
- Выпуск системной библиотеки Glibc 2.33
Теги для поиска: #_utmp, #_wtmp, #_glibc
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 27-Ноя 08:29
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Торстен Кукук (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 =========== Похожие новости
|
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 27-Ноя 08:29
Часовой пояс: UTC + 5