Re: [PATCH] libuuid: Move clock.txt to /run

["Theodore Ts'o" <tytso@mit.edu>]

On Wed, Mar 01, 2023 at 03:26:04PM +0100, Michal Suchánek wrote:
> > Last time I asked about this file on this mailing list, I was
> > informed that clock.txt is supposed to survive reboots.
> > Moving it to /run (or any other tmpfs) would break this.
> 
> What's so valuable in it that it needs to survive?
> 
> I don't have it at all.
> 
> Also the code seems to re-synchronize with the real time clock from time
> to time which makes the content relevant only for limited periods of
> time.

The concern is if the system time goes backwards, this could result in
a duplicative UUID being returned.  This was especially a concern for
systems that were dual-booting with Windows, where Windows set the
real-time clock to localtime, and Linux set the real-time clock to
GMT, and so the real time clock on those systems had a tendency to
bound around a *lot*.

Using a random number generator for clock can help, but it's only 13
bits, so it's certainly not fool-proof.  Given that using a time-based
UUID leaks the MAC address of your ethernet port as well as when the
UUID was generated (which can be interesting when you're curious say,
when a Libreoffice doc was created), in general best practice is to
use the random UUID type, especially given that modern Linux systems
all have the getrandom(2) system call.  That gives you 58 bits of
entropy in the UUID, so that's probably the better way to go.

Cheers,

					- Ted