On 12/03/26 18:01, Roman Bakshansky wrote:
> Hi all,
>
> I'd like to share a draft RFC proposing a complete overhaul of the legacy
> binary logs used for authentication auditing in Linux: lastlog, btmp, utmp,
> and wtmp.
>
> These files, designed decades ago, are running into fundamental limitations:
>
> - Y2038 problem - they use 32-bit timestamps (time_t in lastlog,
> tv_sec in utmpx). Even on 64-bit systems the fields remain 32-bit
> due to ABI constraints, so all Linux systems are affected.
> - No extensibility - any new field (e.g., container ID, service name,
> source IP) requires changing fixed structures, breaking all existing
> tools that read them.
> - Poor query performance - tools like last, lastb, who have to
> scan whole files linearly; with millions of records this becomes
> painfully slow.
> - No atomicity - partial writes during a crash can corrupt logs.
> - Concurrency bottlenecks - multiple writers (sshd, login, etc.)
> contend for the same file with coarse locking.
>
> To address this once and for all, the RFC proposes replacing these logs
> with dedicated shared libraries that use SQLite as the storage backend:
>
> - liblastlog2 - last login time
> - libbtmp2 - failed login attempts
> - libutmp2 - current sessions
> - libwtmp2 - login/logout history
>
> SQLite brings:
> - 64-bit time -> Y2038 solved forever.
> - Indexes -> O(log N) queries instead of full scans.
> - Extensible schema -> new fields can be added without breaking old tools.
> - ACID and WAL mode -> atomic writes and concurrent access.
> - Portability - runs on any Linux system, no systemd dependency.
>
> The full RFC, including preliminary database schemas and API drafts,
> is available in the discussion repository:
>
> https://github.com/bakshansky/linux-auth-logs
>
> I'm looking for feedback on the overall direction, the proposed
> interfaces, and the open questions listed in the document (e.g.,
> library naming, database location, fallback options for embedded
> systems). Please use GitHub Issues for comments, or reply to this
> thread - I'll monitor both.
>
> Thanks for your time and input!
>From the glibc standpoint my plan is just to make the accounting database
function no-op [1] (I hopefully to get this in the next 2.44 release).
And I think Thorsten Kukuk already adapted most of the usages in current
distros [2][3] using similar strategy, along with a better systemd
integration. I am not sure if/when distros are incorporating his work.
[1] https://patchwork.sourceware.org/project/glibc/list/?series=37271
[2] https://www.thkukuk.de/blog/Y2038_glibc_lastlog_64bit/
[3] https://www.thkukuk.de/blog/Y2038_glibc_utmp_64bit/
