Re: GSS Auth issue when user member of lots of AD groups
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jacob Champion <jacob.champion@enterprisedb.com>
Cc: Chris Gooch <cgooch@bamfunds.com>, pgsql-bugs@lists.postgresql.org
Date: 2025-05-22T16:57:14Z
Lists: pgsql-bugs
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Allow larger packets during GSSAPI authentication exchange.
- d98cefe1143e 18.0 landed
- ca70ee6ede1b 16.10 landed
- c81cdffa1f05 13.22 landed
- a7da7914c355 14.19 landed
- 8b0aa7a6b723 17.6 landed
- 39b1d190714a 15.14 landed
Jacob Champion <jacob.champion@enterprisedb.com> writes: > On Thu, May 22, 2025 at 8:46 AM Tom Lane <tgl@sss.pgh.pa.us> 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