On Tue, Jan 25, 2022 at 12:37:09PM +0100, Stanislav Brabec wrote:
> Karel Zak wrote:
> >
> > OK, seems better than my solution ;-) Thanks!
> Actually, I found a very exotic failure of uuidd accessing clock.txt, which
> is not yet covered:
>
> ls -al /var/lib/libuuid/clock.txt
> -rw-rw---- 1 root root 56 Jan 25 11:48 /var/lib/libuuid/clock.txt
> i. e. root owned clock.txt
>
> 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 ...
> If this happens, /var/lib/libuuid/clock.txt is written as root:root by the
> code in libuuid/src/gen_uuid.c:get_clock(). When uuidd is started later, it
> is unable to use clock.txt.
...
> So I think it should be addressed. But I am not sure how to fix it properly
> in the systemd service file.
> ExecStartPre=-/usr/bin/chown uuidd:uuidd /var/lib/libuuid/clock.txt
> does not work:
> /usr/bin/chown: changing ownership of '/var/lib/libuuid/clock.txt':
> Operation not permitted
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>
in theory it means two clock queues, but if uuidd is running then
libuuid/getuuid always uses it.
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).
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
http://karelzak.blogspot.com
