[Phpmyadmin-devel] Limits imposed by Suhosin
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. -- Thanks and Regards, Madhura Jayaratne [1] https://sourceforge.net/tracker/?func=detail&atid=377408&aid=3380946&group_i... [2] http://www.hardened-php.net/suhosin/configuration.html#suhosin.get.max_value... [3] https://sourceforge.net/tracker/?func=detail&aid=3358750&group_id=23067&atid... [4] https://sourceforge.net/mailarchive/message.php?msg_id=27839987
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. -- Marc Delisle http://infomarc.info
On Sun, Aug 7, 2011 at 2:06 PM, Marc Delisle <marc@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?
-- Marc Delisle http://infomarc.info
------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1 _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Le 2011-08-07 07:31, Tyron Madlener a écrit :
On Sun, Aug 7, 2011 at 2:06 PM, Marc Delisle <marc@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. -- Marc Delisle http://infomarc.info
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@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. -- Marc Delisle http://infomarc.info
On Sun, Aug 7, 2011 at 3:01 PM, Marc Delisle <marc@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@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.
-- Marc Delisle http://infomarc.info
------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1 _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Le 2011-08-07 08:20, Tyron Madlener a écrit :
On Sun, Aug 7, 2011 at 3:01 PM, Marc Delisle <marc@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@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? -- Marc Delisle http://infomarc.info
On Sun, Aug 7, 2011 at 3:56 PM, Marc Delisle <marc@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@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@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.
-- Marc Delisle http://infomarc.info
------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1 _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Tyron Madlener a écrit :
On Sun, Aug 7, 2011 at 3:56 PM, Marc Delisle <marc@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@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@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
Marc Delisle a écrit :
Tyron Madlener a écrit :
On Sun, Aug 7, 2011 at 3:56 PM, Marc Delisle <marc@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@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@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
On Mon, Aug 8, 2011 at 5:42 PM, Marc Delisle <marc@infomarc.info> wrote:
Marc Delisle a écrit :
Tyron Madlener a écrit :
On Sun, Aug 7, 2011 at 3:56 PM, Marc Delisle <marc@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@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@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.
Glad to hear that and thanks for testing.
-- Marc Delisle http://infomarc.info
------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1 _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
On Sun, Aug 7, 2011 at 5:01 PM, Tyron Madlener <tyronx@gmail.com> wrote:
On Sun, Aug 7, 2011 at 2:06 PM, Marc Delisle <marc@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
On Sun, Aug 7, 2011 at 4:36 PM, Marc Delisle <marc@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.
Hi Marc, Thank you for the lead given to find what exactly the bug was when I was clueless about it. My apologies for missing it in the initial mail. Yes, I will add a comment to the FAQ and mark the bug as wont fix. -- Thanks and Regards, Madhura Jayaratne
participants (3)
-
Madhura Jayaratne -
Marc Delisle -
Tyron Madlener