Re: Replay attack of query cancel - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Replay attack of query cancel
Date
Msg-id 20080816200337.GD4998@alvh.no-ip.org
Whole thread Raw
In response to Re: Replay attack of query cancel  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Responses Re: Replay attack of query cancel  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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.


pgsql-hackers by date:

Previous
From: "Asko Oja"
Date:
Subject: Re: Patch: plan invalidation vs stored procedures
Next
From: Dimitri Fontaine
Date:
Subject: Re: Plugin system like Firefox