Re: Replay attack of query cancel

From: "Stephen R(dot) van den Berg" <srb(at)cuci(dot)nl>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Gregory Stark <stark(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Replay attack of query cancel
Date: 2008-08-13 13:46:41
Message-ID: 20080813134641.GL12628@cuci.nl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Magnus Hagander wrote:
>Gregory Stark wrote:
>> "Magnus Hagander" <magnus(at)hagander(dot)net> writes:
>> We could have the server indicate it's the new protocol by sending the initial
>> cancel key twice. If the client sees more than one cancel key it automatically
>> switches to new-style cancel messages.

>That will still break things like JDBC I think - they only expect one
>cancel message, and then move on to expect other things.

Why didn't they follow recommended practice to process any message
anytime? Was/is there a specific reason to avoid that in that driver?
(Just curious).

>What would work is using a parameter field, per Stephen's suggestion
>elsewhere in the thread. Older libpq versions should just ignore the
>parameter if they don't know what it is. Question is, is that too ugly a
>workaround, since we'll need to keep it around forever? (We have special
>handling of a few other parameters already, so maybe not?)

You only need to keep the runtimeparameter for as long as you don't bump
the protocol version.
Then again, runtimeparameters are cheap.
--
Sincerely,
Stephen R. van den Berg.

"And now for something *completely* different!"

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2008-08-13 13:59:22 Re: Replay attack of query cancel
Previous Message Markus Wanner 2008-08-13 13:38:32 Re: Transaction-controlled robustness for replication