Re: Replay attack of query cancel

Tom Lane wrote:
> Magnus Hagander <magnus(at)hagander(dot)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.

In EXEC_BACKEND, we already store this in shared memory. If we could
live with doing that for the non-exec case as well, it'd be a lot easier.

And we could then just have the backend update the array when it sends
out a "new key" message.

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

Yeah.

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

That, or rely on something that's not just a simple shared secret
(something like what Andrew Gierth suggested). And AFAICS, his
suggestion allows us to manage without having to update the cancel key
in shared memory at all - but it does require a protocol modification.

//Magnus