allow_url_fopen / allow_url_include and fine grained control

From: Date: Wed, 17 Jan 2007 01:07:15 +0000
Subject: allow_url_fopen / allow_url_include and fine grained control
Groups: php.internals 
Request: Send a blank email to internals+get-27492@lists.php.net to get a copy of this message
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. 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. The short version of the attached patch is this: 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. In addition, they can be set to a colon delimited list of wrapper names (e.g. allow_url_include=file:compress.bz2:compress.zlib ) When used in this manner, the value of a wrapper's is_url flag is meaningless, only the name is considered. If it's in this list, it's allowed, otherwise not. I've also applied the same concept as was recently added to open_basedir, that is; These settings can be tightened during runtime/perdir context (but not loosened). For example, if the system-wide setting for allow_url_fopen is on, and a given script wants to restrict itself to just local files, they can: ini_set("allow_url_fopen", "file"); Comments welcome, flames not. -Sara Note: I changed the internal names for these settings in order to force 3rd party extensions to review their code if they rely on inspecting those values.

« previous php.internals (#27492) next »