[Phpmyadmin-devel] Limits imposed by Suhosin

[Madhura Jayaratne]

On Sun, Aug 7, 2011 at 5:01 PM, Tyron Madlener <tyronx at gmail.com> wrote:

> 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?
>

Suhosin imposes a limit on the length of a single value passed via a GET,
not on the length of the entire URL, so if we are to adhere to it we need to
change the code a bit. And further if we do not wish to comply with it I do
not see a point in doing so.

-- 
Thanks and Regards,

Madhura Jayaratne
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.phpmyadmin.net/pipermail/developers/attachments/20110807/1f9e1158/attachment.html>