Eric Lee / smarc-fsl-linux-kernel

17 Jul, 2007

1 commit

  • f23513e8d   Introduce O_CLOEXEC ... Browse Code »

    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
    #include
    #include
    #include

    #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;
    }

    [kyle@parisc-linux.org: parisc fix]
    Signed-off-by: Ulrich Drepper
    Acked-by: Ingo Molnar
    Cc: Davide Libenzi
    Cc: Michael Kerrisk
    Cc: Chris Zankel
    Signed-off-by: Kyle McMartin
    Acked-by: David S. Miller
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ulrich Drepper
     

08 Sep, 2005

5 commits

17 Apr, 2005

1 commit

  • 1da177e4c   Linux-2.6.12-rc2 ... Browse Code »

    Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds