utmp 64 bit time_t support

utmp 64 bit time_t support

[Adhemerval Zanella Netto]

The gnulib developers has reported that the lack of 64-bit support on utmp
records has created some real issues [1]. This issue is problematic because
now some 32-bit architectures when built with 64-bit time_t support have
a different utmp struct size, which essentially breaks __WORDSIZE_TIME64_COMPAT32
support. The simple straightforward fix would to make utmp/utmpx always 32-bit
for theses architecture (mips, mips64n32, riscv32, sparcv9, and i686) but this 
would be an ABI break.

Thorsten has summarized other issues with the interface [2], and it is even a 
problem for some 64 bit architectures that define __WORDSIZE_TIME64_COMPAT32 
(mips64, powerpc64, riscv64, sparc64, and x86_64) [3][4].

The current implementation also has a security issues [5] that would require a
complete rewrite to move the functionality to a proper service (which poses its
own issues).

Thorsten suggestion would to replace wtmp with journald, which would require
some code rewrite since is has a different ABI. But I think this is the best
way to fix it.

I have sent a possible 64 bit fix [6], but as Joseph has hinted there is not
easy way to maintain compatibility [7].  It would require a lot of work, 
probably some breakage; which I think no one is really interested in fixing.

So I think it is really time to just deprecate these functions, move them to 
compat symbols, and return ENOSYS for new code.

Thoughts?

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=30701
[2] https://github.com/thkukuk/utmpx/blob/main/Y2038.md
[3] https://sourceware.org/bugzilla/show_bug.cgi?id=28146
[4] https://sourceware.org/bugzilla/show_bug.cgi?id=17470
[5] https://sourceware.org/bugzilla/show_bug.cgi?id=24492
[6] https://sourceware.org/pipermail/libc-alpha/2020-July/116742.html
[7] https://sourceware.org/pipermail/libc-alpha/2020-July/116764.html

Re: utmp 64 bit time_t support

[Thorsten Kukuk]

Hi,

On Tue, Aug 01, Adhemerval Zanella Netto via Libc-alpha wrote:

> The gnulib developers has reported that the lack of 64-bit support on utmp
> records has created some real issues [1]. This issue is problematic because
> now some 32-bit architectures when built with 64-bit time_t support have
> a different utmp struct size, which essentially breaks __WORDSIZE_TIME64_COMPAT32
> support. The simple straightforward fix would to make utmp/utmpx always 32-bit
> for theses architecture (mips, mips64n32, riscv32, sparcv9, and i686) but this 
> would be an ABI break.
> 
> Thorsten has summarized other issues with the interface [2], and it is even a 
> problem for some 64 bit architectures that define __WORDSIZE_TIME64_COMPAT32 
> (mips64, powerpc64, riscv64, sparc64, and x86_64) [3][4].
> 
> The current implementation also has a security issues [5] that would require a
> complete rewrite to move the functionality to a proper service (which poses its
> own issues).
> 
> Thorsten suggestion would to replace wtmp with journald, which would require
> some code rewrite since is has a different ABI. But I think this is the best
> way to fix it.

Correction:
1. replace utmp with systemd-logind
   https://github.com/thkukuk/utmpx/blob/main/utmp-to-logind.md
   https://www.thkukuk.de/blog/Y2038_glibc_utmp_64bit/
   https://github.com/thkukuk/utmpx/tree/main/patches
   systemd, shadow, util-linux, procps-ng and Linux-PAM will support
   this. 
2. replace wtmp with (pam_)wtmpdb
   https://github.com/thkukuk/wtmpdb
   https://www.thkukuk.de/blog/Y2038_glibc_wtmp_64bit/
   this is what we did already with openSUSE Tumbleweed and MicroOS and nobody
   noticed so far. So seems to be really compatible.

> So I think it is really time to just deprecate these functions, move them to 
> compat symbols, and return ENOSYS for new code.
> 
> Thoughts?

I like this idea, this would increase the "pressure" for this one, who
think there is still enough time and just wait until it resolves
magically by itself and blocking everything.

But maybe we should wait a little bit, systemd v254, which is the main
pre-requires for this, is really fresh and did not yet arrive in the big
distributions.

  Thorsten

-- 
Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies
SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany
Managing Director: Ivo Totev, Andrew McDonald, Werner Knoblich
(HRB 36809, AG Nürnberg)

Re: utmp 64 bit time_t support

[Paul Eggert]

On 2023-08-01 13:28, Adhemerval Zanella Netto via Libc-alpha wrote:
> The gnulib developers has reported that the lack of 64-bit support on utmp
> records has created some real issues [1]. This issue is problematic because
> now some 32-bit architectures when built with 64-bit time_t support have
> a different utmp struct size, which essentially breaks __WORDSIZE_TIME64_COMPAT32
> support. The simple straightforward fix would to make utmp/utmpx always 32-bit
> for theses architecture (mips, mips64n32, riscv32, sparcv9, and i686) but this
> would be an ABI break.

Isn't there a less-simple but still reasonably-straightforward fix that 
wouldn't break the ABI? On these traditionally-32-bit time_t platforms 
when _TIME_BITS=64, do what Gnulib is doing[8], namely, convert from 
file format to internal format while reading the utmp data.

Obviously this Gnulib hack won't work after the year 2038, but it's 
still a win because struct utmpx doesn't work today. That is, with 
current glibc, utmpx-using programs fail today if compiled with 
_TIME_BITS=64 on 32-bit platforms. This is why I filed glibc bug 30701. 
I suspect this bug will need to be fixed regardless of whether utmpx 
becomes deprecated in the next glibc release.

> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=30701
> [2] https://github.com/thkukuk/utmpx/blob/main/Y2038.md
> [3] https://sourceware.org/bugzilla/show_bug.cgi?id=28146
> [4] https://sourceware.org/bugzilla/show_bug.cgi?id=17470
> [5] https://sourceware.org/bugzilla/show_bug.cgi?id=24492
> [6] https://sourceware.org/pipermail/libc-alpha/2020-July/116742.html
> [7] https://sourceware.org/pipermail/libc-alpha/2020-July/116764.html

[8]: https://lists.gnu.org/r/bug-gnulib/2023-07/msg00159.html

Re: utmp 64 bit time_t support

[Andreas Schwab]

On Aug 04 2023, Paul Eggert wrote:

> Obviously this Gnulib hack won't work after the year 2038,

It could just re-interpret the timestamp field as an unsigned number.
The utmp databases most likely only contain data for a few years at
most, and timestamps from before the epoch are certainly non-existing.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: utmp 64 bit time_t support

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 328 bytes --]

On 2023-08-04 00:28, Andreas Schwab wrote:
> It could just re-interpret the timestamp field as an unsigned number.

Thanks for suggesting that. Although it a hack, it's likely better than 
the hack that was already in Gnulib, so I installed the attached patch 
into Gnulib. We can use this as an idea for fixing glibc bug 30701.

[-- Attachment #2: 0001-readutmp-anticipate-Y2038-hack-for-utmp.patch --]
[-- Type: text/x-patch, Size: 1870 bytes --]

From 0a7a71a4f24b4608662b4532bd17aef758f049fd Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Sat, 5 Aug 2023 11:16:12 -0700
Subject: [PATCH] readutmp: anticipate Y2038 hack for utmp

* lib/readutmp.c (struct utmpx32): Use unsigned int for tv_sec,
not int, as that is more likely to work after 2038.
Suggested by Andreas Schwab in:
https://sourceware.org/pipermail/libc-alpha/2023-August/150661.html
---
 ChangeLog      | 6 ++++++
 lib/readutmp.c | 7 ++++++-
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/ChangeLog b/ChangeLog
index e1437b1b41..80ac7184d8 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,11 @@
 2023-08-05  Paul Eggert  <eggert@cs.ucla.edu>
 
+	readutmp: anticipate Y2038 hack for utmp
+	* lib/readutmp.c (struct utmpx32): Use unsigned int for tv_sec,
+	not int, as that is more likely to work after 2038.
+	Suggested by Andreas Schwab in:
+	https://sourceware.org/pipermail/libc-alpha/2023-August/150661.html
+
 	diffseq: simplify lint removal
 	* lib/diffseq.h (IF_LINT): Remove.
 	Instead, always ignore the diagnostic, as that’s simpler
diff --git a/lib/readutmp.c b/lib/readutmp.c
index ac1c851e97..b8eba076fa 100644
--- a/lib/readutmp.c
+++ b/lib/readutmp.c
@@ -491,7 +491,12 @@ copy_utmp_entry (STRUCT_UTMP *dst, STRUCT_UTMP *src)
     int ut_session;			/* Session ID, used for windowing.  */
     struct
     {
-      int tv_sec;			/* Seconds.  */
+      /* Seconds.  Unsigned not signed, as glibc did not exist before 1970,
+         and if the format is still in use after 2038 its timestamps
+         will surely have the sign bit on.  This hack stops working
+         at 2106-02-07 06:28:16 UTC.  */
+      unsigned int tv_sec;
+
       int tv_usec;			/* Microseconds.  */
     } ut_tv;				/* Time entry was made.  */
     int ut_addr_v6[4];			/* Internet address of remote host.  */
-- 
2.39.2