Bug 43965

Summary: Exim is taking apache port (apache problem)
Product: Apache httpd-2 Reporter: Odeta <odeta>
Component: CoreAssignee: Apache HTTPD Bugs Mailing List <bugs>
Status: RESOLVED FIXED    
Severity: critical CC: sf
Priority: P2    
Version: 2.2-HEAD   
Target Milestone: ---   
Hardware: All   
OS: All   
Bug Depends on: 46425    
Bug Blocks:    

Description Odeta 2007-11-26 11:57:56 UTC 
Please take a look here: http://lists.exim.org/lurker/message/
20060415.062127.564f54cb.en.html

And this is the answer: http://lists.exim.org/lurker/message/
20060417.211007.174ea05d.en.html

Quote:
"It's a bug in Apache: it should mark its listening socket close-on-exec."
Comment 2 Stefan Fritsch 2007-11-27 11:53:50 UTC 
It's not clear that this is an Apache bug. One could argue that mod_php should 
use apr_proc_create instead of using exec. See

http://bugs.php.net/bug.php?id=38915
Comment 3 Lit 2007-12-04 13:05:04 UTC 
Please take a look at http://bugs.php.net/bug.php?id=38915:

[4 Dec 6:43pm UTC] crescentfreshpot at yahoo dot com

Just to add to the dialog, Apache 1.x seems to have tried to address the
issue of leaked FDs itself. http://www.apache.org/dist/httpd/CHANGES_1.3
says:

Changes with Apache 1.3.28

*) Certain 3rd party modules would bypass the Apache API and not
   invoke ap_cleanup_for_exec() before creating sub-processes.
   To such a child process, Apache's file descriptors (lock
   fd's, log files, sockets) were accessible, allowing them
   direct access to Apache log file etc.  Where the OS allows,
   we now add proactive close functions to prevent these file
   descriptors from leaking to the child processes.

As far as I understand the above, apache thinks it can know when
[mod_]php does a system-level popen() and cleanup the parent FDs before
exec(). Is that actually possible?

[4 Dec 7:14pm UTC] stas@php.net

I think that's exactly what FD_CLOEXEC does.
Comment 4 Stefan Fritsch 2009-10-11 07:00:26 UTC 
This has been fixed in apr 1.3.6