Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:27595
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain bitxtender.com from 80.237.132.12 cause and error)
In-Reply-To: <62752.209.254.223.2.1169444659.squirrel@www.l-i-e.com>
References: <45AD76C3.5030303@php.net> <62752.209.254.223.2.1169444659.squirrel@www.l-i-e.com>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-ID: <80CA14A4-B274-4E85-B66B-6898B4202B27@bitxtender.com>
Cc: "Sara Golemon" <pollita@php.net>,
 internals@lists.php.net
Content-Transfer-Encoding: 7bit
Date: Tue, 23 Jan 2007 08:11:30 +0100
To: ceo@l-i-e.com
Subject: Re: [PHP-DEV] allow_url_fopen / allow_url_include and fine grained  control
From: dz@bitxtender.com (=?ISO-8859-1?Q?David_Z=FClke?=)

My understanding is that this coudn't happen because a userspace  
stream would be flagged is_url. So unless someone turns off, say  
"ftp", and then adds "ftp" to the whitelist, there is no problem. And  
if anyone does that, he/she should seriously consider looking for a  
job where he/she can't mess things up that badly :P



Am 22.01.2007 um 06:44 schrieb Richard Lynch:

> On Tue, January 16, 2007 7:07 pm, Sara Golemon wrote:
>> allow_url_fopen and allow_url_include continue to accept boolean  
>> flags
>> in order to behave just as they do now:   true/on allows anything,
>> false/off allows only those wrappers without the is_url bit set.
>
> +1, fwiw.
>
> As far as the "user" being able to implement something otherwise
> dis-allowed...
>
> Well, yeah, they could.
>
> I'm not sure who would really turn off an internal wrapper, then turn
> on "user" then be upset that somebody coded a work-around for a
> blocked internal wrapper...  I mean, that just seems like an unlikely
> real-world sequence of events, in any decent work-place...
>
> I suppose if it's the case of malicious code getting executed, there'd
> be a point, but really, once you have arbitrary malicious PHP code
> getting executed on your box, it's kind of moot if they can then
> download more PHP code to execute, isn't it?...
>
> -- 
> Some people have a "gift" link here.
> Know what I want?
> I want you to buy a CD from some starving artist.
> http://cdbaby.com/browse/from/lynch
> Yeah, I get a buck. So?
>
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>