Re: [PATCH 3/5] login: Add 64-bit time support

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

On 02/08/2020 16:02, Maciej W. Rozycki wrote:
> On Thu, 30 Jul 2020, Adhemerval Zanella via Libc-alpha wrote:
> 
>>>> New symbols for getutent, getutent_r, getutid, getutid_r, getutline,
>>>> getutline_r, getutmp, getutmpx, getutxent, getutxid. getutxline,
>>>> pututline, pututxline, updwtmp, updwtmpx, and login are added to
>>>> all architecture but s390-32 (which already added 64-bit time support
>>>> on 32-bit ABI on glibc 2.9).
>>>
>>> I thought those structures appeared in external files (/var/run/utmp, 
>>> /var/log/wtmp, /var/log/lastlog), which means changing them is problematic 
>>> even with symbol versioning.  Do the files keep their existing formats 
>>> with the new versions of the functions translating to and from the 64-bit 
>>> format when reading / writing those files?  Do they get new formats with 
>>> the old versions of the functions instead being the ones that translate 
>>> (if so, what is the process distributions are expected to use to convert 
>>> existing files on upgrade / enable old wtmp files in the old format to 
>>> continue to be read by new code)?  I think a detailed description of the 
>>> overall strategy for maintaining compatibility with existing data in files 
>>> is needed, both in the patch / patch series description and in the NEWS 
>>> file describing anything required to be done on upgrade to avoid losing or 
>>> corrupting data.
>>>
>>
>> The strategy I used was the same done by s390-32 some time ago, where
>> the var/run/utmp, /var/log/wtmp, /var/log/lastlog would use the new
>> 64-bit time regardless and the 32-bit compat symbols convert the 32-bit
>> entries to the internal 64-bit ones.  Afaik there is not conversion tool 
>> to handle that, so the system administration was supposed to reset such 
>> files in a glibc upgrade.
> 
>  Hmm, there could be many copies of glibc used at once on a single system 
> (e.g. for different ABIs) all accessing the same login records on behalf 
> of different programs, and the intended process has been agreed upon it 
> would seem so that administrators could make the switch as they would see 
> fit rather than being forced to do so at the time of a glibc upgrade: 
> <https://sourceware.org/glibc/wiki/Y2038ProofnessDesign#utmp_types_and_APIs>.

I think the strategy of using new filenames for UTMP_FILE as proposed by Joseph
tends to be a slight better one than keeping multiple databases and add the
extra complexity of syncing entries in multiples files.

On the patches I am working, the default new utmp/utmpx symbols only reads/writes
64-bit time entries. The compat symbols, in the other hand, have a more complex 
logic: if the utmp/utmpx file is the default one (UTMP_FILE exported by newer glibc)
the entries are read as 64-bit and converted to 32-bits; otherwise the register are
read as 32-bit time_t (although it seems unlikely that application using compat
symbols would set the database for the new UTMP_FILE).

The new symbols do not have a logic on how to read old 32-bit database formats.
It should be doable by either setting the file format base on utmp file name 
(through utmpname) or maybe by a GNU extension where the database type is
advertise explicit.  The usefulness of the ABI would be mainly to create some
utmp/wtmp conversion tool, so I am not sure if it is really worth to implement
it.

But the main focus here is to *not* maintain multiple utmp databases, but rather
to move new application to use y2038 ones due the inherent issue of 32-bit time
database (which affects 64-bit architecture as well, modulo s390).  The old 
utmp database should be use only by on compat applications that does not have 
64-bit time support and this is another reason I think the 'utmp.trans' strategy
is not the best one.