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 .
* 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 -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.
