On Fri, Feb 18, 2022 at 04:56:39PM +0100, Stanislav Brabec wrote:
> After a research we realized that only the uuidd provides the guarantee of
> uniqueness of UUIDs across different CPUs and different UIDs.
>
> Without it, there is a probability that two different processes on two
> different CPUs with a different UID will call uuid_generate_time_safe() in
> the same time and generate duplicated UUIDs.
>
> There is a LIBUUID_CLOCK_FILE that should prevent it. But this approach can
> work properly for a single UID only. And creating it world-writable file
> would cause more problems that it will fix.
>
> That is why I propose that uuid_generate_time_safe() should always return -1
> in case that it cannot interact with uuidd.
>
> To realize this, uuid_generate_time_generic() should return -1 instead of
> __uuid_generate_time() return code.
>
> It should not break uuidd, as it calls __uuid_generate_time() directly.
uuid_generate_time_generic() is not API function, so we can do there
whatever :-)
Maybe we need decomposition of complex uuid_generate_time_generic()
into small one-purpose functions and then mix these functions
in uuid_generate_time_safe() and uuid_generate_time().
What about to create small local functions with always only one
purpose and without any fallback:
uuid_generate_time_async() -- random bytes + gettimeofday() or -1
uuid_generate_time_sync_by_file() -- LIBUUID_CLOCK_FILE based or -1
uuid_generate_time_sync_by_uuidd() -- connect() uuidd or -1
public API uuid_generate_time():
uuid_generate_time_sync_by_uuidd() or
uuid_generate_time_sync_by_file() or
uuid_generate_time_async()
public API uuid_generate_time_safe():
uuid_generate_time_sync_by_uuidd() (=return 0) or
uuid_generate_time_sync_by_file() (=return 1) or
-1
and uuidd will always call uuid_generate_time_sync_by_file() and
nothing else.
Yes, it's more work, but it will make code more readable, easy to
maintain and easy to extend in future.
> In the last month, we had a discussion about one clock file per UID in the
> home directory and one for uuidd as a solution of LIBUUID_CLOCK_FILE being
> handled in a first-UID-wins manner. It could improve the situation, but only
> for UUIDs generated by the same UID.
>
> Both changes are partially mutually exclusive: If uuid_generate_time_safe()
> will always return -1, there will be no chance to inform the program, that
> the alternative synchronization was successfully used and that the UUIDs are
> safe in the local context. That it why I propose a small change of API:
>
> Add a new return code of uuid_generate_time_safe().
>
> == RETURN VALUE
>
> The newly created UUID is returned in the memory location pointed to by
> _out_. *uuid_generate_time_safe*() returns zero if the UUID has been
> generated in a safe manner, 1 if the UUID has been generated in a manner
> that is safe for a single UID, -1 otherwise.
Make sense ;-)
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
http://karelzak.blogspot.com
