[Bug time/30701] New: getutxent misbehaves on 32-bit x86 when _TIME_BITS=64

[Bug time/30701] New: getutxent misbehaves on 32-bit x86 when _TIME_BITS=64

[eggert at cs dot ucla.edu]

https://sourceware.org/bugzilla/show_bug.cgi?id=30701

            Bug ID: 30701
           Summary: getutxent misbehaves on 32-bit x86 when _TIME_BITS=64
           Product: glibc
           Version: 2.37
            Status: NEW
          Severity: normal
          Priority: P2
         Component: time
          Assignee: unassigned at sourceware dot org
          Reporter: eggert at cs dot ucla.edu
  Target Milestone: ---

Created attachment 15024
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15024&action=edit
Source code illustrating the bug, when compiled with -m32

A user ran into this problem with Coreutils 'who'.[1] Although we have a
workaround in Gnulib[2] it's hacky as it delves into glibc internals.

This bug is distinct from glibc bug 28146 because it occurs now, not in the
year 2038.

Compile and run the attached program on Fedora 38 with 'gcc -m32 badutmpx.c;
./a.out'. I see output lines like this:

user=reboot id=~~ line=~ pid=0 type=2 tv=2385233251778666.000000

The timestamp is wrong, and the line should look like this:

user=reboot id=~~ line=~ pid=0 type=2 tv=1689108586.555355

The problem is that getutmpx is not converting the external format in
/var/run/utmp with 32-bit timestamps to in-memory format, where time_t is 64
bits not 32.

[1]: https://bugs.gnu.org/64937
[2]: https://lists.gnu.org/r/bug-gnulib/2023-07/msg00159.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug time/30701] getutxent misbehaves on 32-bit x86 when _TIME_BITS=64

[bruno at clisp dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30701

Bruno Haible <bruno at clisp dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bruno at clisp dot org

--- Comment #1 from Bruno Haible <bruno at clisp dot org> ---
Reproduced on
- glibc 2.35 (Ubuntu 22.04)
- glibc 2.36 (Ubuntu 22.10)
- glibc 2.37 (Ubuntu 23.04)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug time/30701] getutxent misbehaves on 32-bit x86 when _TIME_BITS=64

[sam at gentoo dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30701

Sam James <sam at gentoo dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sam at gentoo dot org
           See Also|                            |https://sourceware.org/bugz
                   |                            |illa/show_bug.cgi?id=28146

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug time/30701] getutxent misbehaves on 32-bit x86 when _TIME_BITS=64

[aurelien at aurel32 dot net]

https://sourceware.org/bugzilla/show_bug.cgi?id=30701

Aurelien Jarno <aurelien at aurel32 dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aurelien at aurel32 dot net

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug time/30701] getutxent misbehaves on 32-bit x86 when _TIME_BITS=64

[jwilk at jwilk dot net]

https://sourceware.org/bugzilla/show_bug.cgi?id=30701

Jakub Wilk <jwilk at jwilk dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jwilk at jwilk dot net

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug time/30701] getutxent misbehaves on 32-bit x86 when _TIME_BITS=64

[eggert at cs dot ucla.edu]

https://sourceware.org/bugzilla/show_bug.cgi?id=30701

--- Comment #2 from eggert at cs dot ucla.edu ---
We worked around the problem in Gnulib's readutmp module with the hacky
copy_utmp_entry function in gnulib/lib/readutmp.c. Its source code could be
used for ideas to fix glibc, to benefit applications that don't use Gnulib's
readutmp module.

See:

https://git.savannah.gnu.org/cgit/gnulib.git/tree/lib/readutmp.c

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug time/30701] getutxent misbehaves on 32-bit x86 when _TIME_BITS=64

[bruno at clisp dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30701

--- Comment #3 from Bruno Haible <bruno at clisp dot org> ---
Code for utmp / utmpx conversion (maybe for a different purpose, I don't know)
is already in glibc:
glibc/sysdeps/unix/sysv/linux/s390/s390-32/utmp-convert.h
glibc/sysdeps/unix/sysv/linux/s390/s390-32/utmpx-convert.h

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug time/30701] getutxent misbehaves on 32-bit x86 when _TIME_BITS=64

[bruno at clisp dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30701

--- Comment #4 from Bruno Haible <bruno at clisp dot org> ---
While doing this conversion, the code could interpret the 'tv_sec' field as an
'unsigned int' (as opposed to an 'int'). This would solve the year 2038 problem
at this place. Suggested by Andreas Schwab in
https://sourceware.org/pipermail/libc-alpha/2023-August/150661.html .

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug time/30701] getutxent misbehaves on 32-bit x86 when _TIME_BITS=64

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30701

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |fweimer at redhat dot com
           Assignee|unassigned at sourceware dot org   |fweimer at redhat dot com

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug time/30701] getutxent misbehaves on 32-bit x86 when _TIME_BITS=64

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30701

--- Comment #5 from Florian Weimer <fweimer at redhat dot com> ---
*** Bug 31621 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug time/30701] getutxent misbehaves on 32-bit x86 when _TIME_BITS=64

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30701

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
   Target Milestone|---                         |2.40
             Status|ASSIGNED                    |RESOLVED

--- Comment #6 from Florian Weimer <fweimer at redhat dot com> ---
Fixed for 2.40 via:

commit 9abdae94c7454c45e02e97e4ed1eb1b1915d13d8
Author: Florian Weimer <fweimer@redhat.com>
Date:   Fri Apr 19 14:38:17 2024 +0200

    login: structs utmp, utmpx, lastlog _TIME_BITS independence (bug 30701)

    These structs describe file formats under /var/log, and should not
    depend on the definition of _TIME_BITS.  This is achieved by
    defining __WORDSIZE_TIME64_COMPAT32 to 1 on 32-bit ports that
    support 32-bit time_t values (where __time_t is 32 bits).

    Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>

Backported to all branches with time64 support, up to and including 2.34.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug time/30701] getutxent misbehaves on 32-bit x86 when _TIME_BITS=64

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30701

--- Comment #7 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Bruno Haible from comment #4)
> While doing this conversion, the code could interpret the 'tv_sec' field as
> an 'unsigned int' (as opposed to an 'int'). This would solve the year 2038
> problem at this place. Suggested by Andreas Schwab in
> https://sourceware.org/pipermail/libc-alpha/2023-August/150661.html .

This has been implemented in glibc 2.40 via:

commit 5361ad3910c257bc327567be76fde532ed238e42
Author: Florian Weimer <fweimer@redhat.com>
Date:   Fri Apr 19 14:38:17 2024 +0200

    login: Use unsigned 32-bit types for seconds-since-epoch

    These fields store timestamps when the system was running.  No Linux
    systems existed before 1970, so these values are unused.  Switching
    to unsigned types allows continued use of the existing struct layouts
    beyond the year 2038.

    The intent is to give distributions more time to switch to improved
    interfaces that also avoid locking/data corruption issues.

    Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>

No backports planned.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug time/30701] getutxent misbehaves on 32-bit x86 when _TIME_BITS=64

[lksfbdij at 10mail dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30701

--- Comment #8 from Robert West <lksfbdij at 10mail dot org> ---
Is this change ABI compatible? I see following report in libabigail:

        ┌──────────────────────┐
        │ ABI Break: libc.so.6 │
        └──────────────────────┘
        Functions changes summary: 0 Removed, 2 Changed (13 filtered out), 0
Added functions
        Variables changes summary: 0 Removed, 0 Changed, 0 Added variable
        2 functions with some indirect sub-type change:
          [C] 'function utmp* __getutent()' at getutent.c:27:1 has some
indirect sub-type changes:
            Please note that the exported symbol of this function is
getutent@@GLIBC_2.0
            return type changed:
              in pointed to type 'struct utmp' at utmp.h:58:1:
                type size hasn't changed
                1 data member changes (1 filtered):
                  type of 'long int ut_session' changed:
                    entity changed from 'long int' to compatible type 'typedef
int32_t' at stdint-intn.h:26:1
                      type name changed from 'long int' to 'int'
                      type size hasn't changed
          [C] 'function void getutmp(const utmpx*, utmp*)' at getutmp.c:29:1
has some indirect sub-type changes:
            Please note that the symbol of this function is
getutmp@@GLIBC_2.1.1
             and it aliases symbol: getutmpx@@GLIBC_2.1.1
            parameter 1 of type 'const utmpx*' has sub-type changes:
              in pointed to type 'const utmpx':
                in unqualified underlying type 'struct utmpx' at utmpx.h:55:1:
                  type size hasn't changed
                  1 data member changes (1 filtered):
                    type of 'long int ut_session' changed:
                      entity changed from 'long int' to compatible type
'typedef __int32_t' at types.h:41:1
                        type name changed from 'long int' to 'int'
                        type size hasn't changed

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug time/30701] getutxent misbehaves on 32-bit x86 when _TIME_BITS=64

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30701

--- Comment #9 from Florian Weimer <fweimer at redhat dot com> ---
On 32-bit platforms long int and int32_t are compatible, so this is not the ABI
change.

The ABI change only happens for -D_TIME_BITS=64 (or rather, it no longer
happens relative to -D_TIME_BITS=32), and it is not visible to libabigail
analysis because of the way libc.so.6 is built.

-- 
You are receiving this mail because:
You are on the CC list for the bug.