[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1042562: libc6: broken utmp handling in 32-bit programs with 64-bit time_t



Package: libc6
Version: 2.37-6
Tags: upstream

The utmp(5) interface has broken its compatibility in 32-bit programs
built with -D_TIME_BITS=64.  In bits/utmpx.h we see this:

,----
| /* The fields ut_session and ut_tv must be the same size when compiled
|    32- and 64-bit.  This allows files and shared memory to be shared
|    between 32- and 64-bit applications.  */
| #if __WORDSIZE_TIME64_COMPAT32
|   __int32_t ut_session;		/* Session ID, used for windowing.  */
|   struct
|   {
|     __int32_t tv_sec;		/* Seconds.  */
|     __int32_t tv_usec;		/* Microseconds.  */
|   } ut_tv;			/* Time entry was made.  */
| #else
|   long int ut_session;		/* Session ID, used for windowing.  */
|   struct timeval ut_tv;		/* Time entry was made.  */
| #endif
`----

The definition of __WORDSIZE_TIME64_COMPAT32 can be found in bits/wordsize.h:

,----
| #ifdef __x86_64__
| # define __WORDSIZE_TIME64_COMPAT32	1
| /* Both x86-64 and x32 use the 64-bit system call interface.  */
| # define __SYSCALL_WORDSIZE		64
| #else
| # define __WORDSIZE_TIME64_COMPAT32	0
| #endif
`----

So on i386 (and I suppose on other 32-bit architectures except x32)
ut_tv is of struct timeval, and ut_tv.tv_sec is of time_t, which is
actually a 64-bit integer in programs built with -D_TIME_BITS=64.

One example where this already has caused problems is the who(1) program
which has opted in for -D_TIME_BITS=64, see #1027135.  Once programs
start to _write_ utmp entries with a 64-bit ut_tv.tv_sec rather than
merely reading them, things could become more interesting. :-(


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386


Reply to: