# Lack of read permission on main script leads to E_WARNING

- Thread: https://externals.io/message/19936
- Original archive: https://news-web.php.net/php.internals/19936
- Started by Ryan Dingman on 2005-11-09T19:09:10+00:00
- Messages: 2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #19936 — Ryan Dingman — 2005-11-09T19:09:10+00:00

URL: https://externals.io/message/19936#19936

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

---

## #20077 — Ryan Dingman — 2005-11-16T20:01:33+00:00

URL: https://externals.io/message/19936#20077 · In reply to: #19936

I sent this message last week and haven't received a single reply.  I  
was hoping for someone to either agree that it was a bug and advise  
if/when a patch would be included in PHP or explain why they believe  
that this is the "correct" behavior for PHP.

Thanks in advance,

Ryan Dingman
rdingman@next-online.net
Next Online Mortgage Technologies



>
> 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