В настоящее время для хранения данных о сеансах и попытках аутентификации в Linux используются следующие бинарные файлы, имеющие фиксированную структуру:
- /var/log/lastlog - время последнего входа (структура "struct lastlog" с полем "ll_time" 32-разрядного типа time_t);
- /var/log/btmp - неудачные попытки входа;
- /var/run/utmp - текущие сеансы;
- /var/log/wtmp - история входов и выходов.
Формат данных файлов был разработан несколько десятилетий назад и имеет ряд фундаментальных ограничений:
- Поле "tv_sec" в структуре "utmpx" и поле "ll_time" в "lastlog" имеют тип "int32_t", значение счётчиков времени на основе которого переполнится 19 января 2038 года. Из-за требований ABI‑совместимости даже на 64-разрядных системах эти поля остаются 32-разрядными, поэтому проблема затронет все установки Linux.
- Фиксированный размер записей не позволяет добавлять новые поля (например, идентификатор контейнера, имя сервиса, IP-адрес) без полной замены формата и перекомпиляции всех утилит.
- Утилиты last, lastb, who и lastlog вынуждены линейно перебирать содержимое файлов. При большом размере журналов без использования индексов, позволяющих эффективно фильтровать записи, нагрузка на систему ввода/вывода и задержки при выполнении запросов становятся неприемлемыми.
- Запись в бинарный файл не является атомарной операцией. При сбое запись может быть частично повреждена.
- Для исключения конфликтов при одновременной записи в журнал несколькими процессами (например, sshd и login) используются flock-блокировки, которые не гарантируют атомарность и могут приводить к взаимным блокировкам.
Автор RFC предлагает полностью отказаться от бинарных форматов в пользу специализированных разделяемых библиотек, использующих SQLite. Для каждого типа журналов создаётся отдельная библиотека с единообразным C-интерфейсом: liblastlog2, libbtmp2, libutmp2 и libwtmp2. Все библиотеки работают с БД, схема которых включает 64-разрядные временные метки (тип INTEGER) и индексы по пользователю и времени. Имеется возможность добавления новых полей без нарушения совместимости (через ALTER TABLE).
Среди доводов в пользу использования SQLite упоминается использование 64-разрядного типа INTEGER для хранения эпохального времени, задействование индексов для снижения ввода/вывода за счёт выборочного обращения к записями вместо полного сканирования, возможность добавления новых полей без изменения существующих записей,
поддержка ACID-транзакций, режим WAL (Write-Ahead Logging) для конкурентного доступа без блокировок, проверенная надёжность работы SQLite.
Для обеспечения плавного перехода предлагается стратегия "двойной записи" (dual-write):
- Программы, которые пишут в бинарные файлы (login, sshd, sudo, cron и др.), модифицируются так, чтобы одновременно выполнять запись и в старый бинарный файл, и в новую SQLite-базу через соответствующую библиотеку.
- Разрабатываются новые версии утилит (last2, lastb2, who2, lastlog2), которые читают данные из SQLite-баз, используя индексы для быстрой работы. Старые утилиты продолжают работать с прежними файлами.
- Через несколько лет, когда подавляющее большинство систем обновятся, поддержка записи в старые форматы может быть отключена, а старые утилиты - объявлены устаревшими.
Вопросы, выставленные для дополнительного обсуждения:
- Целесообразность разделения на отдельные библиотеки или объединения в одну (например, libsession2).
- Выбор имён для библиотек и утилит (сохранить исторические названия или перейти к более общим).
- Расположение файлов баз данных (/var/lib/ как для состояния приложений или /var/log/ как для логов).
- Механизм версионирования схемы и миграции.
- Параметры производительности SQLite для различных сценариев (серверы, встраиваемые системы).
- Предоставление fallback-бэкенда, хранящего журналы в упрощённом бинарном формате, для систем, на которых SQLite может оказаться избыточным (например, встраиваемые устройства с жёсткими ограничениями по памяти).
Источник: https://www.opennet.ru/opennews/art.shtml?num=64981
(opennet.ru, основная лента)