Status update on 64-bit time_t and __WORDSIZE_TIME64_COMPAT32

Status update on 64-bit time_t and __WORDSIZE_TIME64_COMPAT32

[Thorsten Kukuk]

Hi,

status update on replacing utmp with logind:

Since about two month openSUSE Tumbleweed and MiroOS are using logind
instead of utmp and since a week they are utmp/wtmp/lastlog free.
Means we don't create /run/utmp, /var/log/wtmp and /var/log/lastlog anymore.

There were a low 1 digit number of bug reports, majority of users didn't
notice the switches to logind, wtmpdb and lastlog2. There was also only
positive feedback on the conferences in the last two month.

Most big upstream projects have already released new versions using
logind instead of utmp, a few like util-linux accepted all PRs, but
haven't released a new version yet.

In my opinion, we have an alternative that works, so that we can add an
option to disable the current utmp/utmpx/wtmp/lastlog API.

What would be the best way to do so?

  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: Status update on 64-bit time_t and __WORDSIZE_TIME64_COMPAT32

[Adhemerval Zanella Netto]

On 08/11/23 07:10, Thorsten Kukuk wrote:
> 
> Hi,
> 
> status update on replacing utmp with logind:
> 
> Since about two month openSUSE Tumbleweed and MiroOS are using logind
> instead of utmp and since a week they are utmp/wtmp/lastlog free.
> Means we don't create /run/utmp, /var/log/wtmp and /var/log/lastlog anymore.
> 
> There were a low 1 digit number of bug reports, majority of users didn't
> notice the switches to logind, wtmpdb and lastlog2. There was also only
> positive feedback on the conferences in the last two month.
> 
> Most big upstream projects have already released new versions using
> logind instead of utmp, a few like util-linux accepted all PRs, but
> haven't released a new version yet.
> 
> In my opinion, we have an alternative that works, so that we can add an
> option to disable the current utmp/utmpx/wtmp/lastlog API.
> 
> What would be the best way to do so?
> 
>   Thorsten
> 

There are multiple issues regarding 64 bit support [1] [2] [3] and a 
potential fix would either require breaking the ABI (as I suggested when 
I started the y2038 and I decided to putting aside due the required work) 
or postpone the issue (as suggested by Andreas [4]).

But I think the current implementation has some design flaws that is not
easy to fix without a complete rewrite [5] [6] (which logind essentially 
does).

The only change I am not sure if whether is really makes sense move
the current implementation to compat symbol.  There it is not guaranteed 
that the UTMP/UTMPX files will exist in future environment, thus making
compat symbols pretty much useless.

And keeping a compat symbol also does not help with some design flags 
like BZ#24492, which I am not sure why it did not raised more security
concerns since it is quite easy to create DoS attacks by preventing 
utmp updates.

My take is just remove all the utmpx code, keep an unified utmp.h/utmpx.h
header with some the required definitions, make _PATH_UTMP/_PATH_WTMP/etc
point to invalid files, add deprecate and warning links stubs saying
the functions does nothing, and make the functions return NULL/ENOTSUP.

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=28146
[2] https://sourceware.org/bugzilla/show_bug.cgi?id=17470
[3] https://sourceware.org/bugzilla/show_bug.cgi?id=30701
[4] https://sourceware.org/pipermail/libc-alpha/2023-August/150661.html
[5] https://sourceware.org/bugzilla/show_bug.cgi?id=22440
[6] https://sourceware.org/bugzilla/show_bug.cgi?id=24492