mirror of
https://github.com/postgres/postgres.git
synced 2025-07-31 22:04:40 +03:00
Make cancel request keys longer
Currently, the 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. Hence make the key longer, to make it harder to guess. The longer cancellation keys are generated when using the new protocol version 3.2. For connections using version 3.0, short 4-bytes keys are still used. The new longer key length is not hardcoded in the protocol anymore, the client is expected to deal with variable length keys, up to 256 bytes. This flexibility allows e.g. a connection pooler to add more information to the cancel key, which might be useful for finding the connection. Reviewed-by: Jelte Fennema-Nio <postgres@jeltef.nl> Reviewed-by: Robert Haas <robertmhaas@gmail.com> (earlier versions) Discussion: https://www.postgresql.org/message-id/508d0505-8b7a-4864-a681-e7e5edfe32aa@iki.fi
This commit is contained in:
@ -4062,7 +4062,7 @@ psql "dbname=postgres replication=database" -c "IDENTIFY_SYSTEM;"
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>Int32(12)</term>
|
||||
<term>Int32</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Length of message contents in bytes, including self.
|
||||
@ -4080,14 +4080,29 @@ psql "dbname=postgres replication=database" -c "IDENTIFY_SYSTEM;"
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>Int32</term>
|
||||
<term>Byte<replaceable>n</replaceable></term>
|
||||
<listitem>
|
||||
<para>
|
||||
The secret key of this backend.
|
||||
The secret key of this backend. This field extends to the end of the
|
||||
message, indicated by the length field.
|
||||
</para>
|
||||
<para>
|
||||
The maximum key length is 256 bytes. The
|
||||
<productname>PostgreSQL</productname> server only sends keys up to
|
||||
32 bytes, but the larger maximum size allows for future server
|
||||
versions, as well as connection poolers and other middleware, to use
|
||||
longer keys. One possible use case is augmenting the server's key
|
||||
with extra information. Middleware is therefore also encouraged to
|
||||
not use up all of the bytes, in case multiple middleware
|
||||
applications are layered on top of each other, each of which may
|
||||
wrap the key with extra data.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
<para>
|
||||
Before protocol version 3.2, the secret key was always 4 bytes long.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
@ -4293,14 +4308,18 @@ psql "dbname=postgres replication=database" -c "IDENTIFY_SYSTEM;"
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>Int32</term>
|
||||
<term>Byte<replaceable>n</replaceable></term>
|
||||
<listitem>
|
||||
<para>
|
||||
The secret key for the target backend.
|
||||
The secret key for the target backend. This field extends to the end of the
|
||||
message, indicated by the length field. The maximum key length is 256 bytes.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
<para>
|
||||
Before protocol version 3.2, the secret key was always 4 bytes long.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
|
Reference in New Issue
Block a user