apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bojan Smojver <bo...@rexursive.com>
Subject Re: apr_file_dup and FD_CLOEXEC revisited
Date Thu, 11 Jun 2009 23:14:14 GMT
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/dev@apr.apache.org/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

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.


View raw message