I believe that I've found a bug in the way that PHP handles
permission problems when accessing the main script.
If I access http://localhost/foo.php and PHP does not have permission
to read foo.php, I get an E_WARNING rather than an E_COMPILE_ERROR
(include vs. require). This is in PHP 5.1 RC4. I've fixed this in a
local build by patching zend_execute_scripts in Zend/zend.c on line
1079. zend_execute_scripts was calling zend_compile_file and passing
ZEND_INCLUDE in as the type argument rather than passing along its
type argument. The old code reads:
EG(active_op_array) = zend_compile_file(file_handle, ZEND_INCLUDE
TSRMLS_CC);
My patched version reads:
EG(active_op_array) = zend_compile_file(file_handle, type TSRMLS_CC);
Because I'm not intimately familiar with the inner workings of the
interpreter, I'm not sure that this is the best way to fix this
problem, but it seems like the most appropriate place that I could find.
In case you are wondering why I care -- we have a PHP module that
monitors PHP errors and redirects our customers to a customer service
page any time that PHP encounters anything that the interpreter
really shouldn't recover from (E_CORE_ERROR, E_ERROR, E_PARSE,
E_COMPILE_ERROR and E_USER_ERROR). The main script not being
readable is certainly a case where we would like to redirect them to
a customer service page. However, having an E_WARNING as the error
makes it difficult to identify this situation because we would now
have to distinguish between this E_WARNING and any others that might
arise in the site. Having an E_COMPILE_ERROR would be much more
definitive and more correct IMHO. Yes, we are taking other steps to
ensure that the permission on the PHP scripts for our site are
correct, but mistakes do happen and we want to guarantee that our
customers have as good an experience as possible in the case of
unexpected errors (as any enterprise site should).
Thoughts?
Thanks,
Ryan Dingman
rdingman@next-online.net
Next Online Mortgage Technologies
