Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:22583
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <001001c65078$f28703b0$88051fac@OHRLVN4523SG>
To: <internals@lists.php.net>
References: <000a01c64fbc$cef29c50$88051fac@OHRLVN4523SG> <44257520.6070304@prohost.org>
Date: Sat, 25 Mar 2006 17:59:41 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=response
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] open_basedir_for_include
From: pollita@php.net ("Sara Golemon")

>> The PDM recommendation covering the removal of safe_mode included a note 
>> on expanding the role of open_basedir.  To that end, I'd like to propose 
>> introducing a new ini option: open_basedir_for_include which would allow 
>> using include/require(_once) on an expanded set of directories than what 
>> open_basedir would otherwise allow.
>>
> Why not just add the dirs you intend to include from to open_basedir 
> directly? It does not prevent arbitrary files from being loaded anyway 
> from those dirs. A simple ob_start() include "file"; ob_get_clean() will 
> happily give you the data. And if you wanted to see the source code, 
> highlight_file() could be used.
>
Well, my thoughts were from a shared server perspective where some data 
resources might want to be made available on a limited (access controlled) 
basis though a set of wrapper methods that scripts written by third parties 
could call without being able to see the insides of.

The example of highlight_file() (and similar approaches like 
token_get_all()) and of course the classic open_basedir defying exec() 
approach are workaroundable of course, but mentioning them makes me realize 
that something as simple as 
include('php://filter/string.base64-encode/resource=/includedir/script.php'); 
could be used to dump the contents which could then be decoded to see the 
original version.  This can also be worked around, but the availability of 
these kinds of sneak-abouts just highlights the fact that what I'm trying to 
accomplish won't be handled by this sort of approach in an effective manner.

Anyrate.  The idea isn't going to work as a security solution.  Might give 
some aid for preventing accidental mess-ups as Rasmus pointed out, but it's 
not an effective counter-measure.  Nevermind and carry on....

-Sara