Karel Zak wrote:
On Tue, Jan 25, 2022 at 12:37:09PM +0100, Stanislav Brabec wrote:
It happens only if more conditions are met:
- /var/lib/libuuid exists
- uuidd is not running nor socket activated
- uuigden --time is called as root
And vice-versa, if you stop uuidd and start uuidgen as normal user you
get EACCES for /var/lib/libuuid/clock.txt, but this use-case is
probably not so important ...
"service uuidd stop" keeps socket activation enabled, so uuidgen
launches uuidd again. No problem appears.
What about to create a user specific clock state file if we cannot access
the default one due to EACCES? Something like:
state_fd = open(LIBUUID_CLOCK_FILE, O_RDWR|O_CREAT|O_CLOEXEC, 0660);
if (state_fd < 0 &7 errno == EACCES) {
snprintf(path, "%s-%d", LIBUUID_CLOCK_FILE, getuid());
state_fd = open(path, O_RDWR|O_CREAT|O_CLOEXEC, 0660);
}
so for the bad use-case:
/var/lib/libuuid/clock.txt
/var/lib/libuuid/clock.txt-<uuidd_uid>
It would work, but:
- It either needs pre-created files or world writable directory.
- It is a predictable name. In case of world writable directory, it is
easy to perform denial of service.
in theory it means two clock queues, but if uuidd is running then
libuuid/getuuid always uses it.
Two clock queues are still better than no clock queue. And once uuidd
starts, only clock.txt-uuidd will be in use. And it sysadmin decides to
run system without uuidd, the it is still better than the previous state
(only root or uuidd can use clock.txt)
Another ideas:
If uid is equal to "uuidd", use /var/lib/libuuid/clock.txt (or change to
/var/lib/uuidd/clock.txt), else use home directory, e. g.
~/.libuuid_clock.txt.
Or a separate service file: uuidd-clock.service with:
ExecStart=chown uuidd:uuidd /var/lib/libuuid/clock.txt
(That one would be still vulnerable to race condition attack. And it
looks ugly.)
I like the home directory solution. It would never make things worse
The important is that in this way we can be sure uuidd is always
successful, and I guess the sensitive use-case (SAP;-) is always about
uuidd. IMHO it's more robust then depend on systemd ExecStartPre (or
so).
Sure, installations without uuidd can never guarantee absolute uniqueness.
--
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
