Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:29940
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain php.net from 85.214.94.56 cause and error)
Date: Wed, 30 May 2007 09:30:24 +0200
Reply-To: Marcus Boerger <helly@php.net>
Message-ID: <133379979.20070530093024@marcus-boerger.de>
To: Stanislav Malyshev <stas@zend.com>
CC: php-dev <internals@lists.php.net>
In-Reply-To: <465CC25E.9080309@zend.com>
References: <464DCB8C.90803@chiaraquartet.net> <464DEF23.3080503@zend.com> <464DF139.6090405@zend.com> <464E1AA8.9050600@php.net> <465CC25E.9080309@zend.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [PATCH] potential solution to user streams + allow_url_include=off
From: helly@php.net (Marcus Boerger)

Hello Stanislav,

  why then not have ini as follows:
allow_url_(fopen|include)_(local|user|remote)
That is 6 for the six cases - or is that too easy?
We could also have the _remote case be an alias to keep the old style
and have full consistency.

best regards
marcus

Wednesday, May 30, 2007, 2:16:30 AM, you wrote:

> According to the plan below, attached is the patch that restricts user 
> streams from executing dangerous operations inside include context. 
> Please comment.

>>>> I think the problem could be solved this way:
>>>> 0. allow_url_include and allow_url_fopen renamed to
>>>> allow_remote_include and allow_remote_fopen (not really necessary,
>>>> just much cleaner, if you don't like it, ignore it for now).
>>>> 1. By default, allow_remote_inclue=0, allow_remote_fopen=1
>>>> 2. Stream can be of three types - remote, local and user/local.
>>>> 3. User streams can be declared when registered as either remote or
>>>> user/local, remote being the default.
>>>> 4. When operation on user/local stream is run, allow_remote_fopen is
>>>> disabled if allow_remote_include was disabled.




Best regards,
 Marcus