Re: Replay attack of query cancel

>>>>> "Magnus" == Magnus Hagander <magnus@hagander.net> writes:
[snip]

I'm looking (at Magnus' suggestion) at implementing this.

There appears to be only one significant obstacle; since the query
cancel message is received _after_ forking a new backend, there has to
be some mechanism for recording the new value of N on success.  This
is obviously fairly easy in the EXEC_BACKEND case, but it seems quite
intrusive a change to have the non-EXEC_BACKEND case use shared memory
as well.

I can think of a couple of other ways to do it (e.g. some standard
Unix pipe tricks) but I'm not sure of what portability assumptions are
usually made. (I'm assuming that Windows always uses EXEC_BACKEND.)
Ideas?

(To sum up the previous discussion, this is the proposal as I understand
it so far:
1. Servers that support secure cancels will report secure_cancel_key in   the startup GUC settings; the value of this
keyis just randomness   (presumably in hex for convenience).
 
2. The server accepts either the old-style or the secure cancel   request from the client, but doesn't allow old-style
requests  once a valid secure request has been seen.
 
3. The client doesn't send secure cancel requests unless   secure_cancel_key was reported. The client may or may not
choose  to send secure cancels based on whether SSL is in use; we can   leave this decision up to the client in
general,even if we make   libpq use secure cancels only in the SSL case.
 

The upshot is that replay protection is automatically available if
both the client and server support it, and the client chooses to use it.
The net protocol change is one new GUC and one new message format for
the cancel message.)

-- 
Andrew.