| From: | "Stephen R(dot) van den Berg" <srb(at)cuci(dot)nl> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Magnus Hagander <magnus(at)hagander(dot)net>, 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 10:14:57 |
| Message-ID: | 20080813101457.GF12628@cuci.nl |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Lane wrote:
>[ thinks for a bit... ] You could make it a change in the cancel
>protocol, which is to some extent independent of the main FE/BE
>protocol. The problem is: how can the client know whether it's okay to
>use this new protocol for cancel?
Two options:
a. Send two cancelkeys in rapid succession at session startup, whereas
the first one is 0 or something. The client can detect the first
"special" cancelkey and then knows that the connection supports
cancelmethod 2.
b. At sessionstartup, advertise a new runtimeparameter:
cancelmethod=plainkey,hmaccoded
which the client can then chose from.
I'd prefer b over a.
--
Sincerely,
Stephen R. van den Berg.
"And now for something *completely* different!"
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Gregory Stark | 2008-08-13 10:43:25 | Re: Replay attack of query cancel |
| Previous Message | Simon Riggs | 2008-08-13 10:06:50 | Re: SeqScan costs |