bug#64937: "who" reports funny dates

[Paul Eggert]

On 2023-08-07 04:22, Bruno Haible wrote:

> Since the fact that /var/run/utmp and /var/log/wtmp are world-readable
> implies that they are world-lockable and thus the DoS bug
> https://sourceware.org/bugzilla/show_bug.cgi?id=24492 applies,
> to me it's clear that both utmp and wtmp needs to go away

Although that bug should be fixed, a fix doesn't require utmp and wtmp 
to go away. It can instead be fixed as Davin McCall suggested in the 
original bug report, by making the files not world-lockable. This should 
be doable on GNU/Linux (and I expect on other platform that support 
these files) by implementing his suggestion. Admittedly the fix has been 
low priority, but that doesn't mean it's not doable.


> sooner than later. My guess is that Fedora and Ubuntu/Debian are only
> waiting for 'who' (coreutils) and 'last' (util-linux / wtmpdb) to
> stop accessing these two files.

It's not just those two programs. Emacs looks at utmp, for example, when 
creating the symlinks it uses to implement its own file locking, because 
 symlink contents contain the boot time (so that Emacs can better 
detect stale locks) and the boot time is retrieved from /var/run/utmp.

I expect that other programs look at utmp and/or wtmp, besides obvious 
candidates like 'login'. A quick scan through my Ubuntu /usr/bin found 
sessreg, for example; it was originally developed for X but is now used 
elsewhere.

Of course a better scheme could be arranged than utmp/wtmp. The problem 
is that it has not been arranged yet and progress in this area has been 
slow.


> > Although Ubuntu does not maintain /var/log/btmp
>
> What do you mean by that?

Oh, my mistake. I checked a workstation that was behind a restrictive 
firewall, and nobody had ever attempted to attack it. You're right, 
Ubuntu maintains btmp.


>    * The /var/log/wtmp argument to "who" and "users" should become deprecated.

If it is deprecated, we'll need a significant overlap period where the 
system both maintains utmp/wtmp/btmp, and also supports an alternative 
system. Ideally applications won't notice the transition, at least if 
they're using the POSIX/glibc interfaces in <utmpx.h>.


>    * Whereas for /var/log/btmp we need to make an effort to continue supporting
>      it, in the same 'who' program that accesses the systemd API for utmp.
>      And access the time stamp in it as an unsigned 32-bit integer, like
>      Andreas Schwab proposed (already implemented).

Although going to unsigned 32-bit integers is an improvement, it stops 
working in the year 2106 unless we install further hacks later. Better 
would be to widen the ?tmp files time_t to 64 bits, as is done on most 
other 64-bit platforms. This would require a flag-day conversion during 
a software upgrade, but that's doable, and <utmpx.h>-based programs 
should work after the upgrade is done.

>      This means:
>      (1) The API of the readutmp module should provide unlimited-length ut_user,
>          ut_host etc. fields always. No more #ifdef UT_USER_SIZE.
>      (2) The readutmp module should use a runtime 'if' rather than a 
> compile-time
>          #if, in order to dispatch between the systemd backend and the 
> file-based
>          backend.
>
>      I'll work on (1) today.

Thanks. Both ideas sound good to me for Gnulib.

One issue with (1) is that readutmp.h currently defines a boatload of 
macros like UT_USER_SIZE, UT_TIME_MEMBER and UT_EXIT_E_TERMINATION that 
aren't needed if every platform simply uses struct gl_utmp. It'd be 
simpler to remove those macros (or move them to readutmp.c). Although it 
is also tempting to leave those macros in readutmp.h for backward 
compatibility, that might be more trouble than it's worth, as readutmp.h 
is already incompatible with how it was a week ago.