Re: [PATCH 4/5] login: User 64-bit time on struct lastlog

[Adhemerval Zanella via Libc-alpha <libc-alpha@sourceware.org>]

On 30/07/2020 13:19, Florian Weimer wrote:
> * Adhemerval Zanella via Libc-alpha:
> 
>> On 29/07/2020 18:14, Andreas Schwab wrote:
>>> On Jul 29 2020, Adhemerval Zanella via Libc-alpha wrote:
>>>
>>>> It is not used directly on any symbol, so there is no need to add
>>>> compat ones.
>>>
>>> struct lastlog is an external type, describing the format of
>>> /var/log/lastlog.
>>>
>>
>> Right, so which would be best way to handle this transition?  My idea
>> would to be approach to consumers, shadow-utils developers for instance,
>> and state the desirable to make glibc y2038 proof and why this interfaces
>> need to be changed.
> 
> Sounds reasonable.  We also have a security bug that is related to
> direct access to these files:
> 
>   <https://sourceware.org/bugzilla/show_bug.cgi?id=24492>
> 
> If we need to mediate access for format translation, maybe this can be
> addressed at the same time?

I think BZ#24492 is another issue and one that is not easily fixed
without some changes on the utmp-file.c internals.  The utmp/utmpx files 
are read by the ut{x} functions and used on programs such as 'who', and
to fully avoid possible F_SETLKW deadlocks the write must synchronize
using a file not accessible by normal users.

The alarm trick mitigates the deadlock issue, but it does not help
with the fact the log entry is not generated.  The bug report suggestion
of using a extra file to act as the lock for write synchronization might
be a better option.  Another possibility is to move to use a daemon broker 
to actually operate on utmp/utmpx, but I also think it is out of the scope.

I am inclined of using the extra lock file, thoughts?