Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:21938
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <7.0.1.0.2.20060218193901.02a18678@zend.com>
Date: Sat, 18 Feb 2006 19:39:31 -0800
To: "Sara Golemon" <pollita@php.net>
Cc: "Wez Furlong" <wez@thebrainroom.com>,
	"internals" <internals@lists.php.net>
In-Reply-To: <001a01c63506$330a0b50$7d051fac@stumpy>
References: <7.0.1.0.2.20060218170026.02a224f8@zend.com>
	<7.0.1.0.2.20060218171430.02a1c038@zend.com>
	<001a01c63506$330a0b50$7d051fac@stumpy>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: [PHP-DEV] Nuking safe_mode
From: andi@zend.com (Andi Gutmans)

Thanks Sara. I'll fix accordingly. Please watch my commits on the 
wrappers and make sure I'm doing the right thing.

At 07:40 PM 2/18/2006, Sara Golemon wrote:
>>>I'm nuking safe_mode and I found something odd. In streams, 
>>>php_plain_files_unlink() only checks php_check_open_basedir() when 
>>>ENFORCE_SAFE_MODE is flagged. I was planning on nuking 
>>>ENFORCE_SAFE_MODE completely. Is this a bug? Or should I rename 
>>>ENFORCE_SAFE_MODE  to ENFORCE_OPEN_BASEDIR?
>>I just saw we have STREAM_DISABLE_OPEN_BASEDIR.
>>Should I just check if that is 0 and do the open_basedir check in that case?
>Agreed.  This slight logic twist got intrduced when unlink was 
>routed through wrapper->ops.  It should be:
>
>if (ENFORCE_SAFE_MODE) { /* safe mode check*/ }
>if (!DISABLE_OPEN_BASEDIR) { /* do open basedir check */ }
>
>Bad news, I'm probably the one who did that, good news the practical 
>fact of the matter is that it'd be uncommon to use both or neither 
>option.  It's more "normal" to use one or the other so the logic 
>as-is isn't particularly harmful, just.... 
>not-entirely-right.  Looking at a quick grep, the only use of 
>wops->unlink() I actually see is the one in 
>ext/standard/file.c:PHP_FUNCTION(unlink) anyway.
>
>-Sara