Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uI9ER-00GbLs-CE for pgsql-bugs@arkaria.postgresql.org; Thu, 22 May 2025 16:57:23 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1uI9EP-005PFW-SB for pgsql-bugs@arkaria.postgresql.org; Thu, 22 May 2025 16:57:21 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uI9EP-005PFO-K9 for pgsql-bugs@lists.postgresql.org; Thu, 22 May 2025 16:57:21 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1uI9EM-000NI9-2d for pgsql-bugs@lists.postgresql.org; Thu, 22 May 2025 16:57:21 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 54MGvE6O1536693; Thu, 22 May 2025 12:57:14 -0400 From: Tom Lane To: Jacob Champion cc: Chris Gooch , pgsql-bugs@lists.postgresql.org Subject: Re: GSS Auth issue when user member of lots of AD groups In-reply-to: References: <1529314.1747928806@sss.pgh.pa.us> Comments: In-reply-to Jacob Champion message dated "Thu, 22 May 2025 09:19:14 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <1536691.1747933034.1@sss.pgh.pa.us> Content-Transfer-Encoding: 8bit Date: Thu, 22 May 2025 12:57:14 -0400 Message-ID: <1536692.1747933034@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Jacob Champion writes: > On Thu, May 22, 2025 at 8:46 AM Tom Lane wrote: >> Hmm. That must be coming from this bit in libpq: >> ... >> which makes it look like gss_init_sec_context wants us to send a >> packet larger than PQ_GSS_SEND_BUFFER_SIZE, which perhaps is a >> plausible thing to happen if the user belongs to enough groups. > Yeah, it seems like we need to be able to handle up to > PG_MAX_AUTH_TOKEN_LENGTH (64k) for that initial ticket, at least? Hmm, unfortunate that that was chosen independent of the GSS limits. > But also, the current behavior is just to fail hard, so if the client > tries to do something extra that also sometimes fails hard, it may not > really be a regression... Yeah, that's a good point. If we simply allowed the initial packet to be bigger, that would extend the set of cases that work, and if the recipient complains (because it predates that change) then it's a case that would have failed anyway, so we've not made anybody's life worse. I'm wondering though if this isn't just pushing the problem out a little further. Is there a good reason to think 64K is enough? regards, tom lane