Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:27505
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain iamjochem.com from 194.109.193.121 cause and error)
Message-ID: <45AE37D7.5010405@iamjochem.com>
Date: Wed, 17 Jan 2007 15:51:03 +0100
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: Ilia Alshanetsky <ilia@prohost.org>
CC: Sara Golemon <pollita@php.net>,  internals@lists.php.net
References: <45AD76C3.5030303@php.net> <5821E0F2-6E5D-434E-B49B-A46E6FE0E8C4@prohost.org>
In-Reply-To: <5821E0F2-6E5D-434E-B49B-A46E6FE0E8C4@prohost.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] allow_url_fopen / allow_url_include and fine grained
 control
From: jochem@iamjochem.com (Jochem Maas)

Ilia Alshanetsky wrote:
> 
> 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.

what what it's worth, my opinion (as a member of the 'larger group of users'):

as an end user I'd rather have the control myself and be the one to blame,
than be at the 'mercy' of extension writers - where I have little to no idea
if an extension behaves or not (and if not if/when it might be corrected).

I see no reason to think that hosting providers & or packages would
think any differently ... unless their lazy and enjoy passing the buck all
the time.

this does presume that good documentation and best-practice recommendations
are available.

rgds,
Jochem (php village idiot by profession)