[BUG] temporary file-descriptor leak

[ÐÐÑÐ ÐÐÑÐÐÐÐÑÐ <socketpair at gmail dot com>]

How to reproduce:
-------------
#!/usr/bin/python
import ctypes

# after os.execl(...) file descriptor from libffi library will leak
---------------

Where is the problem?
Here (closures.c):

----------------------
/* Open a temporary file name, and immediately unlink it.  */
static int
open_temp_exec_file_name (char *name)
{
  int fd = mkstemp (name);

  if (fd != -1)
    unlink (name);

  return fd;
}
-----------------------

This code does not set O_CLOEXEC, so file will not be closed during
execve(), and fd will leak.

How to fix?
if mkostemp() supported on target platform and O_CLOEXEC is supported in open():
---------------------------
mkstemp(name)  -> mkostemp(name, O_CLOEXEC)
(and possibly |O_NOCTTY|O_NOATIME)
---------------------------



if not, we need to use (pthread's???) spinlock in stub function (code
was not tested):
---------------------------
int mkostemp(name, flags)
{
    static pthread_mutex_t our_spinlock = PTHREAD_MUTEX_INITIALIZER;

    int fd = -1, flags;
    pthread_mutex_lock(&our_spinlock);

    fd = mkstemp(name);
    if (fd == -1)
        goto out;

    flags = fcntl(fd, F_GETFD);

    if (flags == -1)
    {
        close(fd);
        fd = -1;
        goto out;
    }

    flags |= FD_CLOEXEC;

    if (fcntl(fd, F_SETFD, flags) == -1)
    {
        close(fd);
        fd = -1;
        goto out;
    }
out:
        pthread_mutex_unlock(&our_spinlock);
        return fd;
}
-----------------------------

Why spinlock needed?
because of race-conditions between threads, that calls exec()
(google knows many places where it discussed)

P.S.
Also, fallocate()+mlock() is a good thing against sparse files,
unexpected hangs and SIGBUSes :)
Also, madvice / fadvice is your friends against cache wars


P.P.S.
Why not to open public bug tracker ?!

-- 
Segmentation fault