> The patch titled
> Introduce O_CLOEXEC
> has been added to the -mm tree. Its filename is
> introduce-o_cloexec-take-2.patch
>
> *** Remember to use Documentation/SubmitChecklist when testing your code ***
>
> See
http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find
> out what to do about this
>
> ------------------------------------------------------
> Subject: Introduce O_CLOEXEC
> From: Ulrich Drepper <drepper@redhat.com>
>
> The problem is as follows: in multi-threaded code (or more correctly: all
> code using clone() with CLONE_FILES) we have a race when exec'ing.
>
> thread #1 thread #2
>
> fd=open()
>
> fork + exec
>
> fcntl(fd,F_SETFD,FD_CLOEXEC)
>
> In some applications this can happen frequently. Take a web browser. One
> thread opens a file and another thread starts, say, an external PDF viewer.
> The result can even be a security issue if that open file descriptor
> refers to a sensitive file and the external program can somehow be tricked
> into using that descriptor.
>
> Just adding O_CLOEXEC support to open() doesn't solve the whole set of
> problems. There are other ways to create file descriptors (socket,
> epoll_create, Unix domain socket transfer, etc). These can and should be
> addressed separately though. open() is such an easy case that it makes not
> much sense putting the fix off.
>
> The test program:
>
> #include <errno.h>
> #include <fcntl.h>
> #include <stdio.h>
> #include <unistd.h>
>
> #ifndef O_CLOEXEC
> # define O_CLOEXEC 02000000
> #endif
>
> int
> main (int argc, char *argv[])
> {
> int fd;
> if (argc > 1)
> {
> fd = atol (argv[1]);
> printf ("child: fd = %d\n", fd);
> if (fcntl (fd, F_GETFD) == 0 || errno != EBADF)
> {
> puts ("file descriptor valid in child");
> return 1;
> }
> return 0;
> }
>
> fd = open ("/proc/self/exe", O_RDONLY | O_CLOEXEC);
> printf ("in parent: new fd = %d\n", fd);
> char buf[20];
> snprintf (buf, sizeof (buf), "%d", fd);
> execl ("/proc/self/exe", argv[0], buf, NULL);
> puts ("execl failed");
> return 1;
> }
