#38915 [Com]: Apache: system() (and similar) don't cleanup opened handles of Apache

ID: 38915 Comment by: crescentfreshpot at yahoo dot com Reported By: dimmoborgir at gmail dot com Status: Open Bug Type: Feature/Change Request Operating System: UNIX PHP Version: 5.2.2, 4.4.7 New Comment: 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? Previous Comments: ------------------------------------------------------------------------ [2007-11-29 20:33:42] odeta at hard dot lt Any news? mail() function is suffering from the same problem, and exim is using Apache port then.. ------------------------------------------------------------------------ [2007-11-25 19:57:51] olafvdspek at gmail dot com Can't you use FastCGI and avoid issues like these completely? ------------------------------------------------------------------------ [2007-10-07 09:33:33] Cruz at guerillamail dot com Ran into the same problem. I'm appalled that a bug this big isn't fixed more than a year after it was reported. ------------------------------------------------------------------------ [2007-07-29 10:48:18] antoine dot bajolet at tdf dot fr Hello, I agree with all contributors : It's a bunch of pain we can't launch a clean process from a PHP web interface. Without any technical consideration, functionally it's a real need to numerous PHP users, and for a long time seeing those bug reports : http://bugs.php.net/bug.php?id=15529 http://bugs.php.net/bug.php?id=15642 http://bugs.php.net/bug.php?id=16548 The only workaround whe found to obtain the result is : - Writing something to a file to tell "hey, there is a process to launch or stop" - Using a cron'ed script to read the file and launch/stop the process if it tells it. And this poor tip is far far from satisfying us. The last response given in 2003 was "Given the nature of PHP's execution architecture this is not possible/practical to implement." But if the Apache API offers a "apr_proc_create()" function, why not using it in mod_php ? There are some other differences between mod_php and php-cli. Regards, Antoine ------------------------------------------------------------------------ [2007-03-05 21:11:51] oliver at realtsp dot com apart from the security considerations mentioned above the fact that mod_php doesn't free the FDs when forking prevents us from forking cleanly. ie we cannot from a web request to mod_php fork a cli process cleanly because it will inherit all the open FDs (ie typically port 80 & 443) even if you use setsid() (or daemon on FreeBSD) etc.. you can see this when you... fork stop apache netstat -an | grep LISTEN your cli process will be LISTENING to port 80 & 443. this is not only a security risk, but it will prevent apache for restarting: (48)Address already in use: make_sock: could not bind to address [::]:443 no listening sockets available, shutting down I have not found any way to close these sockets as they should be because the resource handles are not available in php. If you could at least make these available then we could at least ensure we close them manually. Regards Oliver ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/38915 -- Edit this bug report at http://bugs.php.net/?id=38915&edit=1