Introduce O_CLOEXEC (take >2)
in [Kernel]
|
From: Ulrich Drepper on 31 May 2007 15:00 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/31/2007 Davide Libenzi wrote: > 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. Policies are not the answer. Using such a flag is no big issue. *Iff* we should end up with some form of private file descriptors changing the default for them would be OK, too. But the existing semantics mustn't be touched, even if it is selectable. Trying to fix existing buggy code this way is foolish since it might just as well break assumptions in the same program. - -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFGXxm/2ijCOnn/RHQRAm+wAJ9YD6KsS6T96xChZvS/3yCwCo6+0gCgl0IY y6OxxUcuQ8yGJsiYebkuIMY= =tkxV -----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: Jakub Jelinek on 31 May 2007 15:10 On Thu, May 31, 2007 at 11:46:31AM -0700, Davide Libenzi wrote: > On Thu, 31 May 2007, Ulrich Drepper wrote: > > 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. If open (and all other syscalls that create fds) have O_CLOEXEC (and something similar for other syscalls), then such a policy can be easily implemented on the userland, if desired. Jakub - 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 15:20 On Thu, 31 May 2007, Jakub Jelinek wrote: > On Thu, May 31, 2007 at 11:46:31AM -0700, Davide Libenzi wrote: > > On Thu, 31 May 2007, Ulrich Drepper wrote: > > > 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. > > If open (and all other syscalls that create fds) have O_CLOEXEC (and > something similar for other syscalls), then such a policy can be easily > implemented on the userland, if desired. That, unless you change all the syscalls creating files to accept new parameters, would require a syscall+fcntl operation. That is not atomic (ie, another thread might do exec between the syscall and the fcntl). Again, mine was a general comment, not directed into magically fixing existing buggy code. What I meant, was that the vast majority of MT+exec apps wants all their fds (but an handfull, maybe) to be O_CLOEXEC. So a global, non-inheritable, per-process flag seemed the most straightforward solution. - 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: Linus Torvalds on 31 May 2007 16:00 On Thu, 31 May 2007, Davide Libenzi wrote: > > What I meant, was that the vast majority of MT+exec apps wants all their > fds (but an handfull, maybe) to be O_CLOEXEC. So a global, > non-inheritable, per-process flag seemed the most straightforward > solution. I'm with Uli on this one. "Stateful" stuff is bad. It's essentially impossible to handle with libraries - either the library would have to explciitly always turn the state the way _it_ needs it, or the library will do the wrogn thing. For example, what about libraries that are used to set up stdin/stdout for the forker? This is not unlike floating point rounding. Having stateful rounding (like the i387) is *stupid*. You want per-operation rounding (where *one* of the choices may be "use default"). Exactly because libraries etc will need to control their _own_ internal choices. Linus - 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 16:00 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Davide Libenzi wrote: > What I meant, was that the vast majority of MT+exec > apps wants all their fds (but an handfull, maybe) You never listen when you are told something. Such a statement cannot be made. The application doesn't know what the runtime libraries need (not just libc, libstdc++, libxml, whatever) and vice versa. Policies are always wrong for somebody and changing the standardized behavior is not acceptable. - -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFGXycL2ijCOnn/RHQRAvPfAJ9r77oMkReyf4OG2rVPaFNb5TIYfgCgwp8e mvswKBbe1UlrzlG3oOWYswM= =viNa -----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/
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 Prev: CFS scheduler, -v8 Next: [patch 06/10] Immediate Value - i386 Optimization |