Re: [EXT] Re: GSS Auth issue when user member of lots of AD groups
От | Tom Lane |
---|---|
Тема | Re: [EXT] Re: GSS Auth issue when user member of lots of AD groups |
Дата | |
Msg-id | 1350781.1748384129@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: GSS Auth issue when user member of lots of AD groups (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [EXT] Re: GSS Auth issue when user member of lots of AD groups
|
Список | pgsql-bugs |
Jacob Champion <jacob.champion@enterprisedb.com> writes: > On Sat, May 24, 2025 at 12:37 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> * 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"? I don't think so, because that would create exactly the cross-version discrepancy we need to avoid. (That is, if sender thinks it can do 16384 when receiver's limit is 16384-4, kaboom.) The patch proposes to allow slop in this during the auth phase when the packet size is really being determined by the underlying GSSAPI library anyway. But once we're past that and our own code is slicing up the data stream into packets, I think the max packet size is indeed an inalterable part of the protocol. Could we address your confusion by improving the comment about the packet-size #define to point out that it includes the header word? regards, tom lane
В списке pgsql-bugs по дате отправления: