Re: Replay attack of query cancel

Andrew Gierth wrote:

> 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 think you should look at making the memory used for this shared in
both cases, EXEC_BACKEND and not. The only downside is that shared
memory usage will grow a bit on a minor release, but it'll be tiny. The
portability problems caused by any other trick you use to transmit the
value is probably going to be a lot harder.

> 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.

Hmm, I think there should be a way to turn off acceptance of old-style
without necessarily requiring a new-style request. Otherwise, how are
you protected from DoS if you have never sent a cancel request at all?

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.