Thread: Fwd: Bug#372115: Last security update of postgresql-contrib breaks database replication with DBMirror.pl
Fwd: Bug#372115: Last security update of postgresql-contrib breaks database replication with DBMirror.pl
From
Martin Pitt
Date:
Hi PostgreSQL gurus, we recently received this bug report after we upgraded Debian's stable release to the equivalent of 7.4.13 (with the fixes for quote escaping). Does anyone know DBMirror.pl? The proposed fix seems wrong since it just reverts the behavior to the old quote escaping style. Thank you in advance for any idea, Martin ----- Forwarded message from Olivier Bornet <Olivier.Bornet@puck.ch> ----- Subject: Bug#372115: Last security update of postgresql-contrib breaks database replication with DBMirror.pl Reply-To: Olivier Bornet <Olivier.Bornet@puck.ch>, 372115@bugs.debian.org From: Olivier Bornet <Olivier.Bornet@puck.ch> To: Debian Bug Tracking System <submit@bugs.debian.org> Date: Thu, 08 Jun 2006 12:30:55 +0200 X-Spam-Status: No, score=3D1.3 required=3D4.0 tests=3DBAYES_50,DATE_IN_FUTU= RE_06_12=20 autolearn=3Dno version=3D3.0.3 Package: postgresql-contrib Version: 7.4.7-6sarge2 Severity: critical Justification: causes serious data loss Hello, using version 7.4.7-6sarge2 of postgresql-contrib cause trouble in database replication using /usr/lib/postgresql/bin/DBMirror.pl The problem I have found is if there is a ' character (the single quote) in the data. In this case, the single quote (') is replaced by two single quotes ('') in the table PendingData. This cause the replication process to stop with a message "Error in PendingData Sequence Id XXX". To replicate the non-replicated data, I have run a patched version of DBMirror.pl. Here is my patch (mainly replacing the two single quotes by a backslash and one single quote, this mean '' -> \'. Execepted if there is a equal before, this mean don't replace =3D'') : --- /usr/lib/postgresql/bin/DBMirror.pl 2005-05-18 10:33:34.000000000 +0200 +++ ./DBMirror.pl 2006-06-08 11:53:39.000000000 +0200 @@ -827,6 +827,9 @@ $fnumber =3D 4; my $dataField =3D $pendingResult->getvalue($currentTuple,$fnumber); =20 + # replace all the '' to \' in the texts + $dataField =3D~ s/([^=3D])\'\'/\1\\\'/g; + while(length($dataField)>0) { # Extract the field name that is surronded by double quotes $dataField =3D~ m/(\".*?\")/s; I'm sure this patch is not enough, because this don't take in account if the data has in it something like "=3D''". I think the part to patch is not the DBMirror.pl, but the "recordchange" procedure called by the trigger on each data change. Reverting postgresql-contrib to version 7.4.7-6sarge1 correct the problem only if you have nothing in the Pending table. Thanks for your attention, and have a nice day. Oliver ----- End forwarded message ----- --=20 Martin Pitt http://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org In a world without walls and fences, who needs Windows and Gates?
Martin Pitt wrote: -- Start of PGP signed section. > Hi PostgreSQL gurus, > > we recently received this bug report after we upgraded Debian's stable > release to the equivalent of 7.4.13 (with the fixes for quote > escaping). > > Does anyone know DBMirror.pl? The proposed fix seems wrong since it > just reverts the behavior to the old quote escaping style. Using '' instead of \' allows dbmirror work now that \' throws an error on unsafe encodings. -- Bruce Momjian http://candle.pha.pa.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Re: Fwd: Bug#372115: Last security update of postgresql-contrib breaks database replication with DBMirror.pl
From
Tom Lane
Date:
Martin Pitt <martin@piware.de> writes: > Does anyone know DBMirror.pl? The proposed fix seems wrong since it > just reverts the behavior to the old quote escaping style. I don't know it, but the function being complained of seems exactly the sort of ad-hoc escaping logic that the security update warns you should get rid of. (I fear we failed to notice it because it was in Perl not C :-() I think it should be rewritten from the ground up. Does the Pg Perl module expose PQescapeString by any chance? Relying on that would be far better than letting this code live. regards, tom lane