[PATCH 3/3] login: Make user accounting database no-op

[Adhemerval Zanella Netto]

On 07/08/24 16:06, Thorsten Kukuk wrote:
> On Wed, Aug 7, 2024 at 8:39 PM Adhemerval Zanella Netto
> <adhemerval.zanella@linaro.org> wrote:
>>
>>
>>
>> On 07/08/24 14:27, Thorsten Kukuk wrote:
>>> On Wed, Aug 7, 2024 at 5:23 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
>>>>
>>>> On 2024-08-07 02:20, Thorsten Kukuk wrote:
>>>>> At SUSE/openSUSE all new products don't have /run/utmp nor
>>>>> /var/log/wtmp anymore. But applications checking return code of the
>>>>> utmp/wtmp functions report an error, if this files don't exist.
>>>>
>>>> Do Gnulib-using programs have this problem? For example, does GNU
>>>> coreutils 9.5 work correctly without SUSE needing to patch it?
>>>
>>> I  haven't seen any problems with Gnulib based programs, coreutils has
>>> no open issues and I don't see any patches in this area.
>>> sshd is for example an application which creates a lot of messages
>>> around utmp/wtmp.
>>>
>>
>> It still on my plan to rebase this patch and try to move forwards with
>> this approach.  On 2.40 we changed the way utmp/utmpx to handle the
>> seconds-since-epoch types as unsigned 32-bit type
>> (commit 5361ad3910c257bc327567be76fde532ed238e42); so at least it is
>> not a y2038 issue anymore.
> 
> How should that solve the Y2038 issue?
> I'm not aware of any application which interprets the int32 time value
> as unsigned value. And since this interpretation is done in the
> application and not inside glibc, you need to touch every single line
> of code handling utmp entries.
> With how many projects did you already spoke that they adjust their code?
> And how do applications find out, if the value was written as int or as uint?
> 
> For me this is not a solution for the Y2038, that issue still exists.

It is not and it is explicit stated in the NEWS entry:

* Architectures which use a 32-bit seconds-since-epoch field in struct
  lastlog, struct utmp, struct utmpx (such as i386, powerpc64le, rv32,
  rv64, x86-64) switched from a signed to an unsigned type for that
  field.  This allows these fields to store timestamps beyond the year
  2038, until the year 2106.  Please note that applications are still
  expected to migrate off the interfaces declared in <utmp.h> and
  <utmpx.h> (except for login_tty) due to locking and session management
  problems.

And the patch make is explicit that the intent is to give distributions 
more time to switch to improved interfaces that also avoid locking/data
corruption issues.

The long-term solution is still moving away from current implementation.