#21898 [Opn]: Segfault after Apache internal redirect

ID: 21898 Updated by: iliaa@php.net Reported By: mlippmaa@issp.u-tokyo.ac.jp Status: Open Bug Type: Apache2 related Operating System: RedHat Linux PHP Version: 4.3.0 New Comment: This bug may be related to bug #17868. Previous Comments: ------------------------------------------------------------------------ [2003-01-27 06:21:25] mlippmaa@issp.u-tokyo.ac.jp Using Apache 2.0.43 internal redirects with PHP4.3.0 either cause a segfault or expose a part of the original PHP script. I have an authentication module in Apache, which checks the user access rghts in the ap_hook_auth_checker hook and diverts the user to an error document if authentication fails. The Apache module does this: r->method = apr_pstrdup(r->pool, "GET"); r->method_number = M_GET; ap_internal_redirect(url, r); return OK; If the url of the error document points to a PHP file, the error document is processed immediately, as it should be, but parts of the source text of the original PHP script that the user tried to access is also sent before Apache finishes the request. What happens is that Apache calls the php_output_filter in sapi_apache2.c first with a brigade that only contains the error document's filename. This gets processed normally. Apache then calls the php_output_filter *again* with a brigade that contains the filename of the original PHP script (to which access was denied). The output filter looks at the ctx->request_processed flag, which is now set, and passes the brigade to the next filter. Unfortunately, for some reason at this stage the ctx->r->handler field has been cleared to NULL, which is probably why some other filter downstream actually delivers the PHP script source as text, appended to the original PHP output. The appended text is not visible in the browser, but easy enough to see in a packet dump between the client and the server. If the error document is a HTML file, the same thing happens, except in this case apache makes the second call to the php_output_filter with ctx->r->handler = NULL and ctx->request_processed = 0, which means that the filter code reaches the strncp() that checks if this is a php-source request. Since the handler pointer is NULL, the strncmp call causes a segmentation fault at this point. For all I know, this whole problem could be caused by an incorrect use of the ap_internal_redirect call in Apache, but it may still be a good idea to check that if the PHP output filter does get called, that there really is a non-NULL handler field in ctx->r. ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=21898&edit=1