Se ha publicado una propuesta (RFC) para reemplazar los formatos de registro binarios heredados lastlog, btmp, utmp y wtmp con nuevas bibliotecas compartidas que utilizan SQLite como base de datos, para su discusión en la lista de correo linux-api. La iniciativa busca solucionar varios problemas, incluyendo el desbordamiento de 2038 en contadores de tiempo de 32 bits, la falta de extensibilidad, el bajo rendimiento de las consultas y la falta de atomicidad en la escritura.
Actualmente, para almacenar datos sobre sesiones e intentos de autenticación en Linux Se utilizan los siguientes archivos binarios con una estructura fija:
- /var/log/lastlog — hora del último inicio de sesión (estructura “struct lastlog” con campo “ll_time” de tipo time_t de 32 bits);
- /var/log/btmp — intentos de inicio de sesión fallidos;
- /var/run/utmp — sesiones actuales;
- /var/log/wtmp — historial de inicios y cierres de sesión.
El formato de estos archivos se desarrolló hace varias décadas y presenta una serie de limitaciones fundamentales:
- El campo "tv_sec" de la estructura "utmpx" y el campo "ll_time" de "lastlog" son de tipo "int32_t", cuyo valor, en el que se basan los contadores de tiempo, se desbordará el 19 de enero de 2038. Debido a los requisitos de compatibilidad de la ABI, incluso en sistemas de 64 bits, estos campos siguen siendo de 32 bits, por lo que el problema afectará a todas las instalaciones. Linux.
- El tamaño fijo del registro no permite agregar nuevos campos (por ejemplo, ID del contenedor, nombre del servicio, dirección IP) sin cambiar completamente el formato y recompilar todas las utilidades.
- Las utilidades last, lastb, who y lastlog se ven obligadas a recorrer el contenido de los archivos de forma lineal. Con registros extensos, sin índices que filtren eficazmente los registros, la carga de E/S y la latencia de las consultas se vuelven inaceptables.
- Escribir en un archivo binario no es una operación atómica. Si la escritura falla, el archivo puede quedar parcialmente dañado.
- Para evitar conflictos cuando varios procesos (por ejemplo, sshd y login) escriben en el registro al mismo tiempo, se utilizan bloqueos de tipo flock, que no garantizan la atomicidad y pueden provocar interbloqueos.
El autor de la RFC propone abandonar por completo los formatos binarios y optar por bibliotecas compartidas especializadas que utilicen SQLite. Se está creando una biblioteca independiente con una interfaz C uniforme para cada tipo de registro: liblastlog2, libbtmp2, libutmp2 y libwtmp2. Todas las bibliotecas funcionan con bases de datos cuyo esquema incluye marcas de tiempo de 64 bits (tipo INTEGER) e índices de usuario y de tiempo. Se pueden añadir nuevos campos sin romper la compatibilidad (mediante ALTER TABLE).
Algunos de los argumentos a favor del uso de SQLite incluyen el uso de un tipo INTEGER de 64 bits para almacenar la hora de época, el uso de índices para reducir las operaciones de entrada/salida mediante el acceso selectivo a los registros en lugar de escaneos completos, la capacidad de agregar nuevos campos sin modificar los registros existentes, la compatibilidad con transacciones ACID, el modo WAL (Write-Ahead Logging) para el acceso concurrente sin bloqueos y la fiabilidad demostrada de SQLite.
Para garantizar una transición sin problemas, se propone una estrategia de escritura dual:
- Los programas que escriben en archivos binarios (login, sshd, sudo, cron, etc.) se modifican para escribir simultáneamente tanto en el archivo binario antiguo como en la nueva base de datos SQLite a través de la biblioteca correspondiente.
- Se están desarrollando nuevas versiones de utilidades (last2, lastb2, who2, lastlog2) que leen datos de bases de datos SQLite, utilizando índices para un mejor rendimiento. Las utilidades antiguas siguen funcionando con los mismos archivos.
- En unos años, cuando la gran mayoría de los sistemas se hayan actualizado, es posible que se desactive la compatibilidad con la grabación en formatos antiguos y que las utilidades antiguas se declaren obsoletas.
Preguntas para debatir más a fondo:
- Conviene dividirlas en bibliotecas separadas o combinarlas en una sola (por ejemplo, libsession2).
- Elegir nombres para bibliotecas y servicios públicos (mantener los nombres históricos o cambiarlos por otros más generales).
- Ubicación de los archivos de la base de datos (/var/lib/ para el estado de la aplicación o /var/log/ para los registros).
- Mecanismo de control de versiones y migración de esquemas.
- Parámetros de rendimiento de SQLite para diferentes escenarios (servidores, sistemas embebidos).
- Proporciona un sistema de respaldo que almacena los registros en un formato binario ligero para sistemas donde SQLite puede resultar excesivo (por ejemplo, dispositivos integrados con severas limitaciones de memoria).
Fuente: opennet.ru
