libuuid statefile woes
I experienced the following crash in an application that uses libuuid:
fffffc7fffdf4130 libc.so.1`mutex_lock_impl+0x33(0, 0) fffffc7fffdf4150 libc.so.1`mutex_lock+0x10(0) fffffc7fffdf41d0 libuuid.so.1`uuid_create+0x78(fffffc7fffdf41e0) fffffc7fffdf4230 libuuid.so.1`uuid_generate_time+0x3c(fffffc7fffdf4248) status: process terminated by SIGSEGV (Segmentation Fault), addr=4
This turned out to be a problem with permissions on
/var/tmp, which is another story,
however I found a couple of things:
First is that,
libuuid attempts to maintain a shared and persistent state file in
/var/sadm/system/uuid_state. It does not create this file if it does not exist
so presumably it is supposed to be delivered with some appropriate permissions.
If this file does not exist, the library falls back to a temporary state file via
When the fallback fails (as it did on my broken system), it doesn't fail in a particularly
friendly way, leaving the mutex uninitialised so that the crash occurs somewhere else.
It looks like this
uuid_state file has never been delivered by packaging in the
illumos history, and that the parent directory (
/var/sadm/system/) was removed
commit 4d0eb50e691de4c20b1dd9976ad6839fede8a42d Author: Richard PALO <email@example.com> Date: Wed Dec 17 14:22:16 2014 -0500 4719 update gate build environment to [open]jdk7 4742 update manifests for javadoc7 4743 Fix deprecated /usr/j2se usage in slp and remove from filesystem(5) manpage 4744 remove traces of /var/sadm/system/admin/default_java
We should work out if this shared state file should still be used, and whether by root or by
all users. If so, where should it be maintained (
/var/sadm does not seem appropriate).
We should also make libuuid fail in a better way (earlier) when a state file cannot be created.
Updated by Robert Mustacchi 5 months ago
What's going on here is that when generating a time-based UUID, we are trying to guarantee that when multiple processes are generating a V1 based UUID, that they do not end up overlapping. To do this the shared temporary file contains a robust cross-process lock which allows for ensuring that the sequencing and state is honored across processes.
The use of a temporary file here is somewhat problematic as it means that we could probably generate collisions. Unfortunately, the fix is not very clear to me. In particular, if we reinstated this and made sure the file existed, it would probably mean that it'd be pretty easy to create a denial of service due to the fact that most processes would want this. The solution to that would be to either have a privileged daemon that we make door calls to or a system call to flesh out the v1 uuid.
So, in terms of the questions here, we really need a shared state by all users, but it's not clear how we can trust arbitrary applications to do this themselves.