Re: allow_url_fopen / allow_url_include and fine grained control

From: Date: Wed, 17 Jan 2007 14:51:03 +0000
Subject: Re: allow_url_fopen / allow_url_include and fine grained control
References: 1 2  Groups: php.internals 
Request: Send a blank email to internals+get-27505@lists.php.net to get a copy of this message
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)

« previous php.internals (#27505) next »