Re: 64-bit time_t and __WORDSIZE_TIME64_COMPAT32

[Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>]

On 11/04/23 08:40, Thorsten Kukuk via Libc-alpha wrote:
> 
> Hi,
> 
> to give a short update on this:
> 
> lastlog: see https://www.thkukuk.de/blog/Y2038_glibc_lastlog_64bit/
> 
> openSUSE Tumbleweed and MicroOS use already lastlog2, we are starting now
> to remove the "old" lastlog code and usage. ALP is currently switching
> to it.
> 
> 
> wtmp: see https://www.thkukuk.de/blog/Y2038_glibc_wtmp_64bit/
> 
> Even if many applications write wtmp entries in a chaotic or wrong way,
> there is only one application from relevance reading it: last.
> lslogins reads it, too, don't know how often it is really used. adjtimex
> reads it, too, but I haven't found any application writing this type of
> entries adjtimex tries to read.
> 
> wtmpdb is currently in security review, afterwards we will switch to it,
> too. Everything is already prepared for this.
> 
> 
> utmp: see https://www.thkukuk.de/blog/Y2038_glibc_utmp_64bit/
> 
> systemd accepted the necessary patches, v254 should contain them. First
> upstream projects accepted the necessary adjustements, too. 
> Main usage of utmp is to find out how many users are logged in, else
> there are wall, write, who and w.
> For coreutils patches exist beside who, procps accepted already the
> first bunch, util-linux has open PRs for the next release, Linux-PAM
> accpeted them, too. Will be in the next release the coming days.
> 
> Only problem is openssh, since they know the TTY only after PAM
> authentication and systemd-logind has no interface to adjust the TTY
> later. I will look into this next.
> 
> So from my point of view, dropping lastlog and wtmp should be straight
> forward, utmp will need quite some more work.

Thanks for the follow up, it seems these interface are either legacy or
they are not really meant to be on libc (as musl did). Moving out to use
systemd or an external isolated process along with some IPC is indeed
way better approach.

I wonder if it would be better as a long term to add a switch 
--disable-utmp (similar to --disable-crypt) which just set these functions
to return ENOSYS without any compatibility support.  It is highly unlike 
that we will ever get a proper fix for BZ#24492 [1] or add support for 
64-bit time_t for these interface, which are both either security or 
usability issues.

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=24492