Introduce O_CLOEXEC (take >2)
in [Kernel]
|
From: Nicholas Miell on 31 May 2007 14:30 On Thu, 2007-05-31 at 14:09 -0400, Ulrich Drepper wrote: > diff --git a/include/asm-generic/fcntl.h b/include/asm-generic/fcntl.h > index c154b9d..b847741 100644 > --- a/include/asm-generic/fcntl.h > +++ b/include/asm-generic/fcntl.h > @@ -48,6 +48,9 @@ > #ifndef O_NOATIME > #define O_NOATIME 01000000 > #endif > +#ifndef O_CLOEXEC > +#define O_CLOEXEC 02000000 /* set close_on_exec */ > +#endif > #ifndef O_NDELAY > #define O_NDELAY O_NONBLOCK > #endif O_CLOSEONEXEC, perhaps? We don't want to create another "creat" here... :) -- Nicholas Miell <nmiell(a)comcast.net> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Ulrich Drepper on 31 May 2007 14:40 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nicholas Miell wrote: > O_CLOSEONEXEC, perhaps? Then nobody would know this is equivalent to FD_CLOEXEC. I think the name I propose is fine. - -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFGXxSv2ijCOnn/RHQRAhELAJ9/7pTQeZShV6NDfEx+iVSfD5g02gCeM/y+ E0GvuEg2EBtOmDdI5MEzOG0= =W6hQ -----END PGP SIGNATURE----- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Davide Libenzi on 31 May 2007 14:40 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 majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Davide Libenzi on 31 May 2007 14:50 On Thu, 31 May 2007, Ulrich Drepper wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Davide Libenzi wrote: > > Isn't this better be a global process flag? Default should be, for legacy > > reasons, > > No. Policies are always wrong since it means code that cannot change > the policy (e.g, all runtime libraries) have no access to the > functionality. I cannot set the policy to default to close-on-exit in > glibc all the while the application assumes this is not the case. I was talking for a broader usage, not only glibc centric. Most ppl writing MT+exec apps wants all but (eventually) and handfull of files leaking across the exec boundary. - Davide - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Ulrich Drepper on 31 May 2007 14:50 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Davide Libenzi wrote: > Isn't this better be a global process flag? Default should be, for legacy > reasons, No. Policies are always wrong since it means code that cannot change the policy (e.g, all runtime libraries) have no access to the functionality. I cannot set the policy to default to close-on-exit in glibc all the while the application assumes this is not the case. - -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFGXxcK2ijCOnn/RHQRAmM9AKC5BEIEBsgwhWx09aAMA0CwsesMWQCfScGr vCF+Ih1lDP5rliY8D2Om5vU= =ZShC -----END PGP SIGNATURE----- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|
Next
|
Last
Pages: 1 2 3 4 Prev: CFS scheduler, -v8 Next: [patch 06/10] Immediate Value - i386 Optimization |