[Phpmyadmin-devel] Limits imposed by Suhosin
Marc Delisle
marc at infomarc.info
Mon Aug 8 14:28:53 CEST 2011
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.
--
Marc Delisle
http://infomarc.info
More information about the Developers
mailing list