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

From Tom Lane
Subject Re: Replay attack of query cancel
Date
Msg-id 18802.1218229771@sss.pgh.pa.us
Whole thread Raw
In response to Re: Replay attack of query cancel  (Magnus Hagander <magnus@hagander.net>)
Responses Re: Replay attack of query cancel  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
Magnus Hagander <magnus@hagander.net> writes:
> The problem was (third IIRC here :-P) in other clients, such as the JDBC
> driver (I think that one was checked specifically) which currently only
> accept the BackendKeyData message during startup. All drivers not based
> on libpq would have to be checked and potentially updated, but it's
> sitll a lot easier than DHing or so.

The other problem was getting the new cancel key from the postmaster to
the backend and thence to the client (hopefully in a timely manner),
recognizing that (a) we don't want the postmaster touching shared memory
very much, and certainly not engaging in any locking behavior; (b)
backends feel free to ignore SIGINT when they're not doing anything.

Certainly the prospect of a de facto protocol change is the bigger
problem, but there are nontrivial implementation issues in the server
too.

If we were going to make it a de jure protocol change (ie new version
number) instead of just hoping nobody notices the behavioral difference,
I'd be inclined to think about widening the cancel key, too.  32 bits
ain't that much randomness anymore.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: Replay attack of query cancel
Next
From: "Kevin Grittner"
Date:
Subject: Re: IN vs EXISTS equivalence