Re: [EXT] Re: GSS Auth issue when user member of lots of AD groups

On Sat, May 24, 2025 at 12:37 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> OK, here's a set of draft patches for that.

I haven't reviewed the code in detail yet, but here are some thoughts
on your notes:

> * Is 128kB unreasonably large? I think we may want some daylight
> above 64kB, but I'm not sure how much.

Having a different token limit between gssenc and non-gssenc users
doesn't seem right to me; if you somehow start relying on the much
larger tokens with gssenc, and later want to switch to TLS, you'd
suddenly be out of luck.

(A larger token does apparently help with unconstrained delegation.
But that page I shared from Microsoft upthread is saying that the
deprecation of unconstrained delegation, plus SID compression, means
that 48k should be good enough for anyone. Whether or not that's true
in practice, I don't know, and I think 64k should definitely be our
minimum.)

> * I concluded that the error report that's being given for the case
> is just flat-out bogus.

+1

> * It seems pretty silly to have separate symbols for
> PQ_GSS_SEND_BUFFER_SIZE and PQ_GSS_RECV_BUFFER_SIZE
> when we're requiring those to be the same, so I merged
> them into one symbol PQ_GSS_MAX_PACKET_SIZE.

That seems fine.

> * The backend's secure_open_gssapi allowed received initialization packets
> to be up to buffer-size long, whereas libpq will choke sending them
> if they're more than buffer-size minus sizeof(uint32). This isn't
> actually a bug, since the buffer management is handled in such a way
> that it's safe, but it seems very inconsistent. I changed the limit
> to subtract off sizeof(uint32) in all cases, which incidentally
> allowed removing one variant of the translatable message string.

That discrepancy is confusing to me. Is there a way to standardize
both sides in the other direction, so that they actually handle tokens
up to the "max size"?

--Jacob