On 29/07/2023 17:41, Sven Joachim wrote:
A 32-bit "who" program reports funny login dates:
,----
| $ file src/who
| src/who: ELF 32-bit LSB pie executable, Intel 80386, version 1 (SYSV),
dynamically linked, interpreter /lib/ld-linux.so.2,
BuildID[sha1]=a897e4f7a6dfd45c9245594e3d0b20497472c66d, for GNU/Linux 3.2.0,
with debug_info, not stripped
| $ src/who
| sven tty1 133589088-06-27 20:29
| sven pts/0 121346977-03-14 05:00 (:0)
| sven tty2 50067723-10-30 01:10
| sven pts/1 3442548-06-12 17:26 (:0)
`----
This is with current coreutils git (commit 3cb862ce5f1) configured with
"CC=gcc -m32" on Debian sid/amd64, but the same issue can also be seen
on plain i386. Originally reported by Jakub Wilk in
https://bugs.debian.org/1027135, and I noticed it myself after upgrading
an ancient machine to Debian 12 today.
I think this is due to the unconditional use of 64 bit time_t.
In normal 64 bit mode, glibc organizes that the time_t is 32 bit for the utmp
records,
however it doesn't do this in 32 bit mode, assuming that time_t is 32 bit.
If one configures with --disable-year2038, then 32 bit time_t is used in 32 bit
mode,
and the problem is avoided. However that's a big hammer, disabling 64 bit
time_t everywhere.
I tried a quick build with -D__WORDSIZE_TIME64_COMPAT32=1
which is what glibc uses to force the smaller time types.
However that didn't fix the issue, so I'll need to look a bit more,
and how to get only utmp access restricted to 32 bit types.
Note there was a related query recently to move away from the utmp
interface entirely, since it is currently restricted to 32 bit times,
and so will have year 2038 issues.
cheers,
Pádraig.
