Re: open_basedir enhancement, runtime tightening
| From: | Andrei Zmievski | Date: | Thu, 12 Oct 2006 21:05:16 +0000 |
| Subject: | Re: open_basedir enhancement, runtime tightening | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-26043@lists.php.net to get a copy of this message | ||
I don't have a problem with this.
-Andrei
On Oct 12, 2006, at 2:53 PM, Sara Golemon wrote:
The attached patch changes open_basedir from PHP_INI_SYSTEM to PHP_INI_ALL. Wait now... let me finish. It introduces a custom INI modification handler for open_basedir which allows the option to be set during Startup and Shutdown (PHP_INI_SYSTEM contexts) normally, then for other contexts (Activate/Deactivate {PERDIR} and Runtime) it checks the inbound settings against the current value and applies some logic: If open_basedir hasn't been set yet: It allows any new setting to be applied (unrestrictive to restrictive) If open_basedir is set, then it checks to see if each component of the new setting would be allowable under the rules of the old setting, if they're all good, it allows it. If any component makes the basedir check less restrictive, it fails (diallows) the change. (less-restrictive to more-restrictive). The advantage of doing this is that package authors and/or users of shared hosting who may not have access to making their settings more restrictive can avoid most simple FS inspection attacks caused by buggy script code by adding a single ini_set(basedir(__FILE__)); to the top of their script or setting it with an .htaccess directive. Note that it doesn't do a thing to avoid code inejction attacks as such an attacker could issue ini_restore("open_basedir"); and have the same access to the FS as they would without this patch. I'll grant you it's not a panacea, and it may be more harmful than good by making people think that tightening up open_basedir is enough, but it's something. Talk amongst y'selves.... -Sara <open_basedir.txt>