Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:27504
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain prohost.org from 64.233.162.237 cause and error)
In-Reply-To: <45AD76C3.5030303@php.net>
References: <45AD76C3.5030303@php.net>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-ID: <5821E0F2-6E5D-434E-B49B-A46E6FE0E8C4@prohost.org>
Cc: internals@lists.php.net
Content-Transfer-Encoding: 7bit
Date: Wed, 17 Jan 2007 09:09:15 -0500
To: Sara Golemon <pollita@php.net>
Subject: Re: [PHP-DEV] allow_url_fopen / allow_url_include and fine grained control
From: ilia@prohost.org (Ilia Alshanetsky)


On 16-Jan-07, at 8:07 PM, Sara Golemon wrote:

> allow_url_include has been bashed lately for being "not good  
> enough", and there is a kernel of truth to that, though where the  
> ultimate blame falls if of course a touchy subject.

Not really, I mean is it so difficult to expect the extension writer  
to know that if they are working with remote streams that they should  
set is_url to 1 rather then 0.

> So rather than continue the fight over who's shoulders the job of  
> security should fall on, how about the attached patch which puts a  
> little more power in the hands of the user/site-admin to control  
> what can be treated as a url include, and how it can be treated  
> that way.

I do not think that this is a good idea. Controlling security  
settings via INI is just a recipe for disaster and will only lead to  
problem due to poor configuration choices. Basically you are moving  
the "blame" from extension writers that provide stream wrappers  
(fairly limited group) onto a far larger group of users.

Ilia Alshanetsky