Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:57220
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 209.85.210.170 cause and error)
Message-ID: <4F052C10.30106@lerdorf.com>
Date: Wed, 04 Jan 2012 20:50:24 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: Laruence <laruence@php.net>
CC: Stas Malyshev <smalyshev@sugarcrm.com>, 
 Ferenc Kovacs <tyra3l@gmail.com>,
 Reindl Harald <h.reindl@thelounge.net>, 
 "internals@lists.php.net" <internals@lists.php.net>
References: <CABBJUpc7T2QZm8QiitQ0wZ5RsY=3Jwy_UERSvLT9unNYtJ1mZA@mail.gmail.com> <CABBJUpeN4iJ6mVUKEEz8qxY25zxTmwg8EigpsmxnZGz5xshMhw@mail.gmail.com> <4F048A03.4070408@sugarcrm.com> <CAH-PCH69gV88qnQ7OHhGHSt70oD7f9Z_HCFD7dfW6SmBR6z2tQ@mail.gmail.com> <4F04A172.7080509@sugarcrm.com> <CAH-PCH5BUsrXKLtk6JWCOA8d5+2DxSke3UAnbBraJyGP-YnQnA@mail.gmail.com> <4F04AA8E.6020701@sugarcrm.com> <CAH-PCH6YH3ZxH5XzEm6+gsikaHjyL-pdHyAs=OnFhWqHk0CctQ@mail.gmail.com> <4F04AD6D.80608@php.net> <CAF+90c-6XrWJnL4vOQjjPm=N=fWrMy31wHOeXGccv+KRq5DrVw@mail.gmail.com> <4F04B071.8080102@php.net> <CAKxcST9NhATxVLrOVP9h2Qy9GfuuzreeVMBtH0EqdZf7jPhytg@mail.gmail.com> <4F04B44D.6080208@thelounge.net> <4F04BCF9.30802@lerdorf.com> <CAH-PCH5NLbDH9K3abJ70Z0AMjfwRNcjk5xE6aSs4cvpBR2_k5Q@mail.gmail.com> <4F04BF63.5060309@lerdorf.com> <4F04C427.9050202@sugarcrm.com> <4F04C920.9050105@lerdorf.com> <4F04CB0D.6040703@lerdorf.com> <CABBJUpcXFChrODjdXzhm-_qLZ7sNSQNAEWCJY_BCvXAWPxbPaA@mail.gmail.com>
In-Reply-To: <CABBJUpcXFChrODjdXzhm-_qLZ7sNSQNAEWCJY_BCvXAWPxbPaA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: another fix for max_input_vars.
From: rasmus@lerdorf.com (Rasmus Lerdorf)

On 01/04/2012 08:13 PM, Laruence wrote:
> On Thu, Jan 5, 2012 at 5:56 AM, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:
>> On 01/04/2012 01:48 PM, Rasmus Lerdorf wrote:
>>> On 01/04/2012 01:27 PM, Stas Malyshev wrote:
>>>> Hi!
>>>>
>>>>> Right, like I said in my previous message, if this is caught by
>>>>> display_start_errors, I am ok with it. We need the default/no php.ini
>>>>> file case to not leak information like this.
>>>>
>>>> Just checked - it does not display error if display_startup_errors if
>>>> off, does display if it's on.
>>>
>>> Right, that seems ok. The other thing is that we need to clarify that it
>>> actually only limits the number of variables per nesting level. The
>>> current name and the description doesn't make that clear. You can still
>>> send 1M post vars in a single POST if you just nest them in a 1000x1000
>>> 2d array. Of course, this is likely going to hit the post_max_size
>>> limit, although many sites that do file uploads will have cranked that
>>> way up.
>>
>> Oh, and a final issue to address.
>>
>> This code:
>>
>> for($data=[],$i=0; $i<=999; $i++) $data[$i] = range(0,1001);
>> echo curl_post("http://localhost/index.php",['a'=>$data]);
>>
>> will spew the warning 2000 times.
>>
>> & php post.php | grep Warning | wc -l
>> 2000
>>
> could you try with this new patch:
> https://bugs.php.net/patch-display.php?bug_id=60655&patch=max_input_vars.patch&revision=latest
> ?
> 
> this patch also restrict the json / serializer ,  all of them must
> less than PG(max_input_vars).
> 
> and different with the fix which was commited now,  this patch count
> the num vars in a global scope, that means if there are 2 elements
> which both have 500 elements in post,  the restriction will also
> affect,
> 
> and this patch will not affect the existsing called to json or
> serializer,   only affect the zif_json_decode and zif_serialize,
> after patch, the serialize will have a sencode parameter :"$max_vars".
> 
> and the restriction can also be closed by set max_input_vars to 0.

Right, I don't think this is going to work. A simple 'make install'
after applying your patch fails with:

Warning: unserialize(): Unserialized variables exceeded 1000 in
phar:///home/rasmus/php-src/branches/PHP_5_4/pear/install-pear-nozlib.phar/PEAR/Registry.php
on line 1145

Warning: unserialize(): Unserialized variables exceeded 1000 in
phar:///home/rasmus/php-src/branches/PHP_5_4/pear/install-pear-nozlib.phar/PEAR/Registry.php
on line 1145

Warning: unserialize(): Unserialized variables exceeded 1000 in
phar:///home/rasmus/php-src/branches/PHP_5_4/pear/install-pear-nozlib.phar/PEAR/Registry.php
on line 1145
[PEAR] PEAR: pear.php.net/PEAR not installed

I really don't think this manual per-feature limiting is going to cut it
here. The real problem is the predictability of the hashing which we can
address by seeding it with a random value. That part is easy enough, the
hard part is figuring out where people may be storing these hashes
externally and providing some way of associating the seed with these
external caches so they will still work.

-Rasmus