Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:20077
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Mime-Version: 1.0 (Apple Message framework v746.2)
In-Reply-To: <6338BF88-958B-460E-8CE4-CDB89F8FCEEA@next-online.net>
References: <6338BF88-958B-460E-8CE4-CDB89F8FCEEA@next-online.net>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-ID: <0D29C3F4-17A6-408D-A252-D2615D7AFAED@next-online.net>
Content-Transfer-Encoding: 7bit
Date: Wed, 16 Nov 2005 12:01:33 -0800
To: internals@lists.php.net
Subject: Re: Lack of read permission on main script leads to E_WARNING
From: rdingman@next-online.net (Ryan Dingman)


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

On Nov 9, 2005, at 11:09 AM, Ryan Dingman wrote:

>
> 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
>