Horton

Re: Make query cancellation keys longer

Peter Eisentraut <peter@eisentraut.org>

View thread View on postgr.es
From: Peter Eisentraut <peter@eisentraut.org>
To: Heikki Linnakangas <hlinnaka@iki.fi>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2024-03-01T14:19:23Z
Lists: pgsql-hackers 
On 29.02.24 22:25, Heikki Linnakangas wrote:
> Currently, cancel request key is a 32-bit token, which isn't very much 
> entropy. If you want to cancel another session's query, you can 
> brute-force it. In most environments, an unauthorized cancellation of a 
> query isn't very serious, but it nevertheless would be nice to have more 
> protection from it. The attached patch makes it longer. It is an 
> optional protocol feature, so it's fully backwards-compatible with 
> clients that don't support longer keys.

My intuition would be to make this a protocol version bump, not an 
optional feature.  I think this is something that everyone should 
eventually be using, not a niche feature that you explicitly want to 
opt-in for.

> One complication with this was that because we no longer know how long 
> the key should be, 4-bytes or something longer, until the backend has 
> performed the protocol negotiation, we cannot generate the key in the 
> postmaster before forking the process anymore.

Maybe this would be easier if it's a protocol version number change, 
since that is sent earlier than protocol extensions?

Commits

  1. Add timingsafe_bcmp(), for constant-time memory comparison

  2. Add missing declarations to pg_config.h.in

  3. docs: Add a new section and a table listing protocol versions

  4. Make cancel request keys longer

  5. libpq: Add min/max_protocol_version connection options

  6. libpq: Handle NegotiateProtocolVersion message differently

  7. docs: Update phrase on message lengths in the protocol

  8. libpq: Trace all NegotiateProtocolVersion fields

  9. libpq: Add PQfullProtocolVersion to exports.txt

  10. Move cancel key generation to after forking the backend