Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58938
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 209.85.161.170 cause and error)
Message-ID: <4F610FB9.1060309@lerdorf.com>
Date: Wed, 14 Mar 2012 14:38:01 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Pierre Joye <pierre.php@gmail.com>
CC: PHP internals <internals@lists.php.net>
References: <4F60F4B1.5010407@lerdorf.com> <CAEZPtU6TBV_WrZ_OBY_3EiGO+G5gYQWYDDuKOOfxF3-gO2X-JQ@mail.gmail.com>
In-Reply-To: <CAEZPtU6TBV_WrZ_OBY_3EiGO+G5gYQWYDDuKOOfxF3-gO2X-JQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Let parse_str() parse more than max_input_vars args
From: rasmus@lerdorf.com (Rasmus Lerdorf)

On 03/14/2012 01:32 PM, Pierre Joye wrote:
> hi Rasmus,
> 
> As the ini_all option sounds appealing, I can imagine ISPs willing to
> do not allow their users to change this value, and that's something I
> would not allow random users either.
> 
> I'd to go with the optional argument, adding a clear in the
> documentation about the confusing error message.

But Pierre, you understand that by the time you ini_set() it in the code
it can only ever affect parse_str() calls. Normal GPC parsing is done
prior to the PHP script running so there is no way for a userspace
script to ini_set() themselves to a state where they will be insecure to
a remote attack. They would have to go out of their way to specifically
write code to do that and that is something they can obviously do anyway
by simply building a big hash from some external source. So I don't
really think this is a valid concern. If this was a real concern I would
think you would have objected to the current INI_PERDIR. This is where a
user can make his scripts unsafe by disabling max_input_vars in a
.htaccess file.

-Rasmus