Re: [RFC] uuid_generate_time_safe() without uuidd should always return -1

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Karel Zak wrote:
On Fri, Feb 18, 2022 at 04:56:39PM +0100, Stanislav Brabec wrote:

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:


It could make the code a bit more readable for sure.

  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

It looks good.

and uuidd will always call uuid_generate_time_sync_by_file() and
nothing else.

Well, good idea. We could make a breaking change there: If the uuid_generate_time_sync_by_file() fail, the whole uuidd will fail, not trying any fallback.

It causes an ugly mis-behavior: Just now, any soft error that happens in the uuidd does not cause the UUIDs being recognized as unsafe.

Example:
chown root:root /var/lib/libuuid/clock.txt
service uuidd restart # It cannot access /var/lib/libuuid/clock.txt any more.
uuid_generate_time_safe()
will now return 0, but UUID is apparently unsafe.

as long as it succeeds.

Yes, it's more work, but it will make code more readable, easy to
maintain and easy to extend in future.

I agree. It was really hard to understand what is actually happening there, and why uuidd does not go into recursion.

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 ;-)

Do you think that we could make such API change (3 return values instead 2)?

I think that most implementations compare with zero, so it should be OK.

--
Best Regards / S pozdravem,

Stanislav Brabec
software developer
---------------------------------------------------------------------
SUSE LINUX, s. r. o.                         e-mail: sbrabec@xxxxxxxx
Křižíkova 148/34 (Corso IIa)                    tel: +420 284 084 060
186 00 Praha 8-Karlín                          fax:  +420 284 084 001
Czech Republic                                    http://www.suse.cz/
PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76



[Index of Archives]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux