O_NOSTD

The real userspace solution would be for programs to just close unknown file descriptors between fork and exec. But they don't, so O_CLOEXEC is a decent facility for defensive library programing.

Yes, this is what I've been saying -- see previous comment regarding "close_everything_but". The bug is in the code that calls fork/exec, not the code that opens a file descriptor!

Comments like this one just show how insane this whole thing is. The *bug* there is that libuuid doesn't close fds before execing a long-lived daemon! It should not be the responsibility of everyone to open all their fds with O_NOEXEC.

I don't see it. Never mind pthread_atfork() -- after all, the issue is exec, not fork. The alternative to O_CLOEXEC for a library that opens files under the covers would seem to be a prepare_for_exec() function exported by the library. The user makes sure he calls that before any exec().

As for the multithreaded program, it already has to serialize access to these file-descriptor-using functions anyway (you wouldn't want two threads opening that file at the same time), so it might as well synchronize prepare_for_exec() with those. This serialization could be done either in the library (i.e. the library is thread-safe), or outside. Oh, and here comes pthread_atfork(): it can make sure the serialization mechanism survives a fork that may precede the exec.

#include <pthread.h>

static int fd = -1;
static pthread_mutex_t fd_lock = PTHREAD_MUTEX_INITIALIZER;

static void mylib_beforefork() {
    pthread_mutex_lock(&fd_lock);
}

static void mylib_afterfork() {
    pthread_mutex_unlock(&fd_lock);
}

void mylib_dosomething() {
    pthread_mutex_lock(&fd_lock);
    if(fd == -1) {
        pthread_atfork(mylib_beforefork, 
                       mylib_afterfork, 
                       mylib_afterfork);
        fd = open(...);
        fcntl(fd, F_SETFD, O_CLOEXEC);
    }
    pthread_mutex_unlock(&fd_lock);

    do_something(fd);
}