On Thu, 31 May 2007, Ulrich Drepper wrote: > I've brought this topic up before but didn't provide a patch. Well, here > we go again, this time with a patch. I even throw in a test program. > > 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.
Isn't this better be a global process flag? Default should be, for legacy reasons, !FD_CLOEXEC. But then you can call a sys_task_set_fflags(FD_CLOEXEC) and all newly created files get that behavior by default. Then, in case you want some of them to cross the exec boundary, you explicitly fcntl(fd, F_SETFD, !FD_CLOEXEC). Most the MT+exec apps I write, would like FD_CLOEXEC for everything anyway. - Davide - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
