On 13/03/26 14:48, Roman Bakshansky wrote:
> On 3/13/26 4:59 PM, Adhemerval Zanella Netto wrote:
>> 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/
> Thank you for the links and information.
>
> I have been following Thorsten Kukuk's work. I know that liblastlog2 is
> already integrated into util-linux and successfully solves the Y2038 problem
> for lastlog. I am also aware of his wtmpdb project. These are important steps
> in the right direction.
>
> My RFC proposes to go further and provide a unified solution for all four
> files: lastlog, btmp, utmp, wtmp. The idea is to create a set of public
> libraries (liblastlog2, libbtmp2, libutmp2, libwtmp2) with a consistent C
> interface, built on SQLite. This would provide 64-bit timestamps, indexes for
> fast queries, ACID transactions, and schema extensibility without breaking
> backward compatibility.
I think you will need to check with the systemd developers whether they are
willing to integrate this idea into their plans (if they haven't already). I
recall that systemd is extensive in some form. My understanding is that
eventually all distros, at least the ones that are systemd-based, will use
the systemd-provided framework instead of relying on different libraries.
>From the glibc standpoint, providing this was always problematic, and I
shared Rich's view (musl creator) that the interface is insecure and legacy
[1].
If I were to implement something not systemd-based, I would follow the
direction that utmps used[2]: a daemon as the only authority to handle the
files and all clients (utmp{x}.h} uses will just query through IPC.
It means that users should not care whether how or where the database is
placed (the _PATH_UTM and related macro should be handled as legacy and
deprecated), and the client should only care about the record structure
in the usual C form, along with a version (so no extra concepts on how the
record is placed in the file).
But I wouldn't put any extra effort into a different API as you did; rather,
I'd check how to adapt legacy programs to work better with systemd. These
interfaces are really legacy, and I think we should move away from them.
[1] https://www.openwall.com/lists/musl/2012/03/04/4
[2] https://skarnet.org/software/utmps/
