allow_url_fopen / allow_url_include and fine grained control
| From: | Sara Golemon | 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.