[Phpmyadmin-devel] Limits imposed by Suhosin

[Marc Delisle]

Marc Delisle a écrit :
> Tyron Madlener a écrit :
>> On Sun, Aug 7, 2011 at 3:56 PM, Marc Delisle <marc at infomarc.info> wrote:
>>> Le 2011-08-07 08:20, Tyron Madlener a écrit :
>>>> On Sun, Aug 7, 2011 at 3:01 PM, Marc Delisle <marc at infomarc.info> wrote:
>>>>> Le 2011-08-07 07:39, Marc Delisle a écrit :
>>>>>> Le 2011-08-07 07:31, Tyron Madlener a écrit :
>>>>>>> On Sun, Aug 7, 2011 at 2:06 PM, Marc Delisle <marc at infomarc.info> wrote:
>>>>>>>> Le 2011-08-06 07:59, Madhura Jayaratne a écrit :
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> While attending to a bug [1], I came across the following.
>>>>>>>>> Suhosin imposes a limit of 512 on the length of the variable that can be
>>>>>>>>> passed via a GET [2]. This is often problematic as in PMA we encounter long
>>>>>>>>> parameters (long sql queries, where clauses when no unique key is there
>>>>>>>>> etc). Due to the same problem [3] $cfg['LinkLengthLimit'] configuration was
>>>>>>>>> lowered to more stricter 1000 from 2000, which is more acceptable.
>>>>>>>>>
>>>>>>>>> In this particular bug the problem is that, though the URL length is under
>>>>>>>>> 1000, one parameter, 'sql_query', violates the Suhosin limit. What
>>>>>>>>> should be our stand on this. Should we adhere to Suhosin default values?
>>>>>>>>>
>>>>>>>>> In 3.5 we have a possible solution for this [4] and we can still lower
>>>>>>>>> $cfg['LinkLengthLimit'] value without losing the look and feel. However this
>>>>>>>>> needs to have JS enabled and I'm not sure whether we want to impose that
>>>>>>>>> condition for the 3.4 series.
>>>>>>>> Madhura,
>>>>>>>> see Documentation.html, FAQ 1.38. You might want to add a suggestion
>>>>>>>> there about suhosin.get.max_value_length.
>>>>>>>>
>>>>>>>> As you can deduce from this FAQ entry, it was not our intention to adapt
>>>>>>>> to Suhosin's limits.
>>>>>>> Would there be any problem in using min($cfg['LinkLengthLimit'],
>>>>>>> [suhoins max length]) for pma?
>>>>>> You might have a good start of solution, but $cfg['LinkLengthLimit'] is
>>>>>> for the total length of the link, whereas suhosin.get.max_value_length
>>>>>> is per parameter and we have more than one parameter in those links.
>>>>>>
>>>>> Also, looking at FAQ 1.38, many Suhosin parameters require tuning for
>>>>> phpMyadmin; this is why phpMyAdmin emits (by default) a warning on its
>>>>> main page about Suhosin, pointing to this FAQ entry.
>>>>>
>>>>> If someone disabled the warning, it's their choice.
>>>>>
>>>> Seeing that many linux distributions like debian ship php with suhosin
>>>> per default many users must be affected by issues with suhosin. And
>>>> suhosin is not just your average addon, it adds important security
>>>> enhancements to php. Disabling it can have severe consequences.
>>>>
>>>> Marking that bug entry as "won't fix" is an indirect statement that we
>>>> either don't care about the users with php+suhosin or that we don't
>>>> care about the users security (forcing them to disable suhosin).
>>>>
>>>> Having phpMyAdmin working with suhosin is a completely valid feature
>>>> request and should be handled as such, in my opinion. Not saying that
>>>> we have to implement that feature now, but the possibilities
>>>> definitely should be kept open.
>>> Continuing Tyron's idea, here is a possible fix. PMA_linkOrButton()
>>> currently checks the whole URL length and decides to generate a link or
>>> form based on this.
>>>
>>> In the form generation logic, it breaks the URL with parse_url(). This
>>> parse_url could occur earlier in the function, enabling a verification
>>> of the length of each parameter value against
>>> suhosin.get.max_value_length and forcing to use the "form" logic as soon
>>> as one of the values will exceed the limit.
>>>
>>> Anyone with a Suhosin-enabled server wants to try this?
>>>
>> Attached patch should implement this behavior, though not tested yet.
> 
> Thanks. I have pushed your patch to origin/master as I don't have 
> Suhosin here to test; so we'll test on the demo server.

Tested, fix confirmed.

-- 
Marc Delisle
http://infomarc.info