From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Gregory Stark <stark(at)enterprisedb(dot)com> |
Cc: | 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 11:19:04 |
Message-ID: | 48A2C328.4070200@hagander.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Gregory Stark wrote:
> "Magnus Hagander" <magnus(at)hagander(dot)net> writes:
>
>> Yeah, that's the point that will require a protocol bump, I think. Since
>> there is no response to the cancel packet, we can't even do things like
>> sending in a magic key and look at the response (which would be a rather
>> ugly hack, but doable if we had a success/fail response to the cancel
>> packet).
>
> From the server point of view we could accept either kind of cancel message
> for the first cancel message and set a variable saying which to expect from
> there forward. If the first cancel message is an old-style message then we
> always expect old-style messages. If it's a new-style message then we require
> new-style messages and keep track of the counter to require a monotically
> increasing counter.
>
> From the client point-of-view we have no way to know if the server is going to
> accept new-style cancel messages though. We could try sending the new-style
> message and see if we get an error (do we get an error if you send an invalid
> cancel message?).
No, that is the point I made above - we don't respond to the cancel
message *at all*.
> 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.
> Or we could just bump the protocol version.
Yeah, but that would kill backwards compatibility in that the new libpq
could no longer talk to old servers.
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?)
//Magnus
From | Date | Subject | |
---|---|---|---|
Next Message | Dmitry Koterov | 2008-08-13 11:29:48 | Patch: propose to include 3 new functions into intarray and intagg |
Previous Message | Andrew Chernow | 2008-08-13 11:19:03 | Re: C Extension woes |