Re: [EXT] Re: GSS Auth issue when user member of lots of AD groups - Mailing list pgsql-bugs

From Tom Lane
Subject Re: [EXT] Re: GSS Auth issue when user member of lots of AD groups
Date
Msg-id 2089825.1748542158@sss.pgh.pa.us
Whole thread Raw
In response to Re: [EXT] Re: GSS Auth issue when user member of lots of AD groups  (Jacob Champion <jacob.champion@enterprisedb.com>)
Responses Re: [EXT] Re: GSS Auth issue when user member of lots of AD groups
List pgsql-bugs
Jacob Champion <jacob.champion@enterprisedb.com> writes:
> On Tue, May 27, 2025 at 3:15 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Could we address your confusion by improving the comment about the
>> packet-size #define to point out that it includes the header word?

> Yes, I think so.

Here's a delta patch responding to your review comments so far:
knock the max auth-packet size down to 64k, and annotate the
size macros as including the header word.

If you're planning to spend more time looking at this, please
let me know, otherwise I'll go ahead and push the fixes.

            regards, tom lane

diff -pud be-secure-gssapi.c~ be-secure-gssapi.c
--- be-secure-gssapi.c~    2025-05-29 13:56:23.359900699 -0400
+++ be-secure-gssapi.c    2025-05-29 13:59:54.931254443 -0400
@@ -49,16 +49,15 @@
  * Therefore, this #define is effectively part of the protocol
  * spec and can't ever be changed.
  */
-#define PQ_GSS_MAX_PACKET_SIZE 16384
+#define PQ_GSS_MAX_PACKET_SIZE 16384    /* includes uint32 header word */
 
 /*
  * However, during the authentication exchange we must cope with whatever
  * message size the GSSAPI library wants to send (because our protocol
  * doesn't support splitting those messages).  Depending on configuration
- * those messages might be as much as 64kB.  To provide some safety margin
- * we use 128kB buffers during transport negotiation.
+ * those messages might be as much as 64kB.
  */
-#define PQ_GSS_AUTH_BUFFER_SIZE 131072
+#define PQ_GSS_AUTH_BUFFER_SIZE 65536    /* includes uint32 header word */
 
 /*
  * Since we manage at most one GSS-encrypted connection per backend,
diff -pud fe-secure-gssapi.c~ fe-secure-gssapi.c
--- fe-secure-gssapi.c~    2025-05-29 13:56:23.359900699 -0400
+++ fe-secure-gssapi.c    2025-05-29 13:59:59.988262778 -0400
@@ -50,16 +50,15 @@
  * Therefore, this #define is effectively part of the protocol
  * spec and can't ever be changed.
  */
-#define PQ_GSS_MAX_PACKET_SIZE 16384
+#define PQ_GSS_MAX_PACKET_SIZE 16384    /* includes uint32 header word */
 
 /*
  * However, during the authentication exchange we must cope with whatever
  * message size the GSSAPI library wants to send (because our protocol
  * doesn't support splitting those messages).  Depending on configuration
- * those messages might be as much as 64kB.  To provide some safety margin
- * we use 128kB buffers during transport negotiation.
+ * those messages might be as much as 64kB.
  */
-#define PQ_GSS_AUTH_BUFFER_SIZE 131072
+#define PQ_GSS_AUTH_BUFFER_SIZE 65536    /* includes uint32 header word */
 
 /*
  * We need these state variables per-connection.  To allow the functions

pgsql-bugs by date:

Previous
From: "Hayato Kuroda (Fujitsu)"
Date:
Subject: RE: Logical replication 'invalid memory alloc request size 1585837200' after upgrading to 17.5
Next
From: Jacob Champion
Date:
Subject: Re: [EXT] Re: GSS Auth issue when user member of lots of AD groups