[horde] Session overflow

Claude Tompers claude.tompers at restena.lu
Tue Feb 19 13:42:19 UTC 2013


On 02/19/2013 01:25 AM, Michael M Slusarz wrote:
> Quoting Claude Tompers <claude.tompers at restena.lu>:
>
>> On 02/17/2013 07:22 AM, Michael M Slusarz wrote:
>>> Quoting Claude Tompers <claude.tompers at restena.lu>:
>>>
>>>> Hello,
>>>>
>>>> We just found some powerusers in our horde system with Session data in
>>>> MySQL bigger than 64k (max size of type blob) causing horde to
>>>> crash and
>>>> log them out.
>>>> MySQL cuts the serialized session object after 64k so when Horde reads
>>>> it again, it is not valid anymore.
>>>> We changed the SessionHandler.Session_Data column in the horde
>>>> database
>>>> to mediumblob (16M) and the problem disappeared immediately.
>>>>
>>>> Is this a known issue ?
>>>
>>> Yes - in fact, it is expressly mentioned in the main horde
>>> configuration file (horde/config/conf.xml).
>> My conf.xml only mentions the horde_prefs table, not the SessionHandler.
>> Are there other tables that can have the same issue ?
>
> Sure.  Any database table you are using that contains blob-ish data.
>
>>>> I suppose we are not the only ones with such
>>>> power users.
>>>> Shouldn't Horde log warnings of such overflows from MySQL ?
>>>
>>> IIRC, there is no warning (at least there used to not be).  MySQL
>>> silently discards all data over 64 KB.
>> I talked to my colleague who said that it is possible that MySQL does
>> not only send a warning, but a fatal error in these conditions.
>> He pointed me to the following document :
>> http://dev.mysql.com/doc/refman/5.0/en/server-sql-mode.html#sqlmode_strict_all_tables
>>
>> Would this be possible to do in Horde or are there other restrictions ?
>
> Patches are welcome.  I personally have no idea how mysql works since
> I don't use it.
I attached a patch for the mysqli driver. It has only a small flaw, a
return code 'false', this is somewhere ignored.
The interface indicates that the changes have been applied regardless of
the return code.
However, if Hunk#1 is applied, the 'bad' data is never written into the
database, thus avoiding misery when PHP tries to make sense out of the
data again.

regards,
Claude

>
> michael
>
> ___________________________________
> Michael Slusarz [slusarz at horde.org]
>


-- 
Claude Tompers
Ingénieur réseau et système
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

-------------- next part --------------
A non-text attachment was scrubbed...
Name: horde-mysqli-catch-warnings.patch
Type: text/x-patch
Size: 1587 bytes
Desc: not available
URL: <http://lists.horde.org/archives/horde/attachments/20130219/8e00e2c0/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.horde.org/archives/horde/attachments/20130219/8e00e2c0/attachment-0001.bin>


More information about the horde mailing list