Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83992
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.43 as permitted sender)
Message-ID: <54F0540C.1040807@gmail.com>
Date: Fri, 27 Feb 2015 11:25:00 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAGa2bXYf7Bi1QPya96t0Z3cQkTWBCOG2p2gCLZSUTY=_gNp_kw@mail.gmail.com>
In-Reply-To: <CAGa2bXYf7Bi1QPya96t0Z3cQkTWBCOG2p2gCLZSUTY=_gNp_kw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Remove allow_url_include INI
From: rowan.collins@gmail.com (Rowan Collins)

Yasuo Ohgaki wrote on 27/02/2015 03:44:
> Hi all,
>
> This is RFC for removing "allow_url_include" INI option. [1]
>
> During "Script only include" RFC[2] discussion, stream wrapper issue is
> raised.
> I was thinking this issue as a separate issue, but it seems others are not.

I'm not convinced by the argument that because "phar://blah" looks like 
a URL, allowing it makes allow_url_include broken. Perhaps it would be 
better named allow_remote_include, but it corresponds to masking out 
your PHP_STREAM_REMOTE flag further down, which is the more important 
protection. If you want to be able to disable phar:// access, you could 
add something like allow_local_stream_include for that case without 
breaking BC.

I'm also not at all clear what you mean by "caller" and "callee" 
responsibilities; surely the difference is just between a global option 
(ini_set()) and a local one (extra argument)? And in what way does 
Option #2 require more changes than Option #1, since they both require 
the argument to be present whenever a stream wrapper is used?

I do think local options are better than global ini settings in many 
cases, but include/require/etc are statements, not functions, so giving 
them extra arguments is awkward - some of your examples are "wrong" in 
this regard:

// Redundant brackets make this look like a function, but it's not:
include('phar://phar_file/script.php');
// I can add as many as I like, the parser is just resolving them to a 
single string expression:
include(((('phar://phar_file/script.php'))));
// This is the actual syntax:
include'phar://phar_file/script.php';
// Implying this for arguments:
include'phar://phar_file/script.php', 'phar://';
// You could explicitly allow a "function form" of the statements, so 
you could parse this:
include(('phar://phar_file/' . $script_name), 'phar://');
// But then you've got a subtle BC break, because the interpretation of 
this changes:
include ($foo) . ('.php');

Regards,
-- 
Rowan Collins
[IMSoP]