Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:26043
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain gravitonic.com from 204.11.219.139 cause and error)
In-Reply-To: <B0.05.22864.D4D9E254@pb1.pair.com>
References: <B0.05.22864.D4D9E254@pb1.pair.com>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-ID: <C925AD16-C358-4E5F-8635-2619E50FE4B2@gravitonic.com>
Cc: internals@lists.php.net
Content-Transfer-Encoding: 7bit
Date: Thu, 12 Oct 2006 16:05:16 -0500
To: Sara Golemon <pollita@php.net>
Subject: Re: [PHP-DEV] open_basedir enhancement, runtime tightening
From: andrei@gravitonic.com (Andrei Zmievski)

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>