Bug #14571


libuuid statefile woes

Added by Andy Fiddaman 4 months ago. Updated 4 months ago.

lib - userland libraries
Start date:
Due date:
% Done:


Estimated time:
Gerrit CR:


I experienced the following crash in an application that uses libuuid:

fffffc7fffdf4130`mutex_lock_impl+0x33(0, 0)

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 tmpfile().

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 <>
    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.

Actions #1

Updated by Robert Mustacchi 4 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.


Also available in: Atom PDF