On Thu, 2009-06-11 at 18:10 +0200, Stefan Fritsch wrote: > I finally got around to test the stderr reopening behaviour with the > various FD_CLOEXEC bits in trunk. I noticed that this still does not > work, i.e. when mod_php exec()s another program, stderr gets closed. > > The problem is in apr_file_dup2(). It should retain the > INHERIT/NOCLEANUP flags of new_file, but currently it checks those > flags in old_file. There was some discussion about this starting at > http://www.mail-archive.com/[email protected]/msg21357.html > > The attached patch fixes the behaviour. With it, a program exec()ed by > mod_php has exactly stdin, stdout, and stderr open, and nothing else.
Thanks! Applied. > With the patch, I think the FD_CLOEXEC bits can be backported to 1.4. > The relevant commits are > 747990 > 748361 > 748371 > 748565 > 748988 > 749810 Thanks for the summary. I had all those written down on a piece of paper (somewhere, I swear :-), but this is way better. > One remaining problem is that when apr is compiled with these changes > on a recent linux kernel, it won't run on older kernels due to the > various new syscalls missing. Therefore, maybe it is not a good idea > to backport this to 1.3. Or one could disable the use of the new > syscalls for 1.3. I think we discussed this before. Any APR/APU feature that is compiled/linked in won't work on any system that doesn't have support for it. I don't think we are guaranteeing that binaries will be portable between systems like that. If we did, we'd have to check for the availability of everything at run time. This would be a huge overhead. So, in my opinion, this is a non-issue. Distributors will know what their kernel and libs supports. So will the people compiling APR/APU themselves. I would personally like to see this backported to both 1.4.x and 1.3.x (because it closes potential security holes), but I think others don't agree with that. -- Bojan
