Dne 01. 04. 22 v 11:21 Karel Zak napsal(a):
Hi,
I'd like to invest time to libuuid and uuidd in the next v2.39.
Stanislav had same ideas and a lot of research in libuuid code to
make things more stable, and I'd like to improve testability of the
all UUID stack we have in util-linux.
TODO:
* uuid_generate_* functions refactoring to make things readable and
to separate ways how UUIDs are generated
Yes, it makes sense.
* clean up uuidd to generate UUID only by the most robust UUIDs way
without any fallback (use uuid_generate_time_sync_by_file())
Yes.
* report all issues on uuidd stderr
Yes. Or even exit with error on any (potentially permanent) issue.
But more important:
All issues should generate error to the libuuid. Otherwise the
application gets downgraded unsafe UUIDs without properly detecting it.
* optionally keep clockfile (/var/lib/libuuid/clock.txt) in uuidd hands
to make sure the file is not shared with other users if the system
is only-uuidd based; for example add --clock-file uuidd option to
overwrite libuuid default.
I guess it is mandatory, otherwise we will have a problem of the root
stealing of the lock file.
The proposed default was ~/.libuuid_clock.txt
There should be an internal function that sets the path to the clock
file. It probably makes sense to make the path configurable in the
config file, but the function should not be public:
- Only uuidd and the configuration read will use the function.
- Applications on systems systems without writable home could configure
it e. g. to /run.
- Using different paths for different applications would cause bad
things; private function makes it impossible.
- It will ensure that nothing else than uuidd will use
/var/lib/libuuid/clock.txt.
I have applied a temporary work-around for the root stealing problem:
uuidd.service:
ExecStartPre=+-/usr/bin/chown uuidd:uuidd /var/lib/libuuid/clock.txt
But it is ugly and it cures just a symptoms and does not work with older version of systemd.
* invite our SAP friends to the upstream development to share ideas
and requirement :-)
* rewrite misc-utils/test_uuidd.c to something commonly usable
(uuidinfo tool?) and use it in util-linux regression tests,
features:
- detect if uuidd is running
- add statistics to the uuidd (number of generated UUIDs,
clients, errors, ...)
- add new UUIDD_OP_* to the uuidd to get additional information
about the daemon (paths, statistics, etc.)
- stress test (like the current test_uuidd.c)
* anything else?
Add support for three levels of safe state for uuid_generate_time_safe():
- Absolutely safe (uuidd was used, and there was no error in uuidd). The
UUID is guaranteed to be unique.
- Safe for the current UID (clock file was used, but no uuidd). The UUID
is guaranteed to be unique for the current UID, but there is no
guarantee that other UIDs.
- Unsafe (clock file use failed, uuidd use failed). The UUID is not
guaranteed to be unique at all. Just a random.
It opens a discussion whether the new return value should be integrated
to the current functions, or add a new function with three return
values. Or even change the current function to the macro, so the newly
compiled code will stop to use the old function name.
If we will change the API, then no code will fail. But the result will
depend on the check implementation:
If the return value will be compared by == -1, it will catch only the
unsafe return.
If the return value will be compared by != 0, it will catch both unsafe
and current-UID-safe.
--
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
