Re: [EXT] Re: GSS Auth issue when user member of lots of AD groups - Mailing list pgsql-bugs
| From | Chris Gooch |
|---|---|
| Subject | Re: [EXT] Re: GSS Auth issue when user member of lots of AD groups |
| Date | |
| Msg-id | DS0PR22MB59712B2BCB379739D97CBA06BE99A@DS0PR22MB5971.namprd22.prod.outlook.com Whole thread Raw |
| In response to | Re: GSS Auth issue when user member of lots of AD groups (Tom Lane <tgl@sss.pgh.pa.us>) |
| Responses |
Re: [EXT] Re: GSS Auth issue when user member of lots of AD groups
|
| List | pgsql-bugs |
Thanks both.
It now makes sense to me. I believe the KDC will not allow tokens larger than 65535 bytes, so feel it is safe from a GSS perspective.
Thanks
Chris
From: Tom Lane <tgl@sss.pgh.pa.us>
Sent: Thursday, May 22, 2025 5:57:14 PM
To: Jacob Champion <jacob.champion@enterprisedb.com>
Cc: Chris Gooch <cgooch@bamfunds.com>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
Subject: [EXT] Re: GSS Auth issue when user member of lots of AD groups
Sent: Thursday, May 22, 2025 5:57:14 PM
To: Jacob Champion <jacob.champion@enterprisedb.com>
Cc: Chris Gooch <cgooch@bamfunds.com>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
Subject: [EXT] Re: GSS Auth issue when user member of lots of AD groups
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
> 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
This email and any attachments should not be construed as an offer or recommendation to sell or buy or a solicitation of an offer to sell or buy any specific security, fund or instrument or to participate in any particular investment strategy. The information contained herein is given as of a certain date and does not purport to give information as of any other date. Although the information presented herein has been obtained from sources we believe to be reliable, no representation or warranty, expressed or implied, is made as to the accuracy or completeness of that information. Past performance is not indicative of future results.
CONFIDENTIALITY NOTICE: This message and any attachment are confidential. If you are not the intended recipient, please telephone or email the sender and delete this message and any attachment from your system. If you are not the intended recipient you must not copy this message or attachment or disclose the contents to any other persons.
Balyasny Asset Management (UK) LLP is authorised and regulated by the Financial Conduct Authority in the UK. Balyasny Asset Management LP is registered as an Investment Advisor with the Securities and Exchange Commission in the USA.
BAM prohibits all personnel from having any business related communications over text message or other unapproved communication applications. Unless pre-approved, BAM employees are only permitted to communicate over email, Bloomberg and BAM telephone lines.
CONFIDENTIALITY NOTICE: This message and any attachment are confidential. If you are not the intended recipient, please telephone or email the sender and delete this message and any attachment from your system. If you are not the intended recipient you must not copy this message or attachment or disclose the contents to any other persons.
Balyasny Asset Management (UK) LLP is authorised and regulated by the Financial Conduct Authority in the UK. Balyasny Asset Management LP is registered as an Investment Advisor with the Securities and Exchange Commission in the USA.
BAM prohibits all personnel from having any business related communications over text message or other unapproved communication applications. Unless pre-approved, BAM employees are only permitted to communicate over email, Bloomberg and BAM telephone lines.
pgsql-bugs by date: