Re: [EXT] Re: GSS Auth issue when user member of lots of AD groups
| От | Chris Gooch |
|---|---|
| Тема | Re: [EXT] Re: GSS Auth issue when user member of lots of AD groups |
| Дата | |
| Msg-id | DS0PR22MB597134B3D28AC101C8936007BE9BA@DS0PR22MB5971.namprd22.prod.outlook.com обсуждение исходный текст |
| Ответ на | 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 |
Hi Both, Will anyone be working on a fix for this bug?
Thanks
Chris
From: Tom Lane <tgl@sss.pgh.pa.us>
Sent: Thursday, May 22, 2025 6:58:33 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 6:58:33 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 9:57 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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?
> Microsoft docs [1] seem to imply that there are still a bunch of
> existing problems if you try to go much higher, though it is possible
> to do so with registry tweaks. Looks like they default to 48k.
> Maybe we should consider making the max incoming ticket size
> configurable, so users that really need a bigger one can deal with the
> DoS risk without it affecting everyone else. (A limit on outgoing
> tickets probably doesn't make too much sense; I imagine you're going
> to use the ticket that GSSAPI hands you, no matter how big it is,
> because it's not as if you have a choice.)
Yeah, but we don't want to change the packet size used after the
initial exchange, because that would create compatibility issues
in cases that aren't failing today. I didn't look at the code
to see if we can easily use a different buffer size during
the authentication exchange. If we can, I'd be inclined to goose
it up to 128K or so. Given Chris' point that should be plenty,
so I don't feel a need to expose a knob.
regards, tom lane
> On Thu, May 22, 2025 at 9:57 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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?
> Microsoft docs [1] seem to imply that there are still a bunch of
> existing problems if you try to go much higher, though it is possible
> to do so with registry tweaks. Looks like they default to 48k.
> Maybe we should consider making the max incoming ticket size
> configurable, so users that really need a bigger one can deal with the
> DoS risk without it affecting everyone else. (A limit on outgoing
> tickets probably doesn't make too much sense; I imagine you're going
> to use the ticket that GSSAPI hands you, no matter how big it is,
> because it's not as if you have a choice.)
Yeah, but we don't want to change the packet size used after the
initial exchange, because that would create compatibility issues
in cases that aren't failing today. I didn't look at the code
to see if we can easily use a different buffer size during
the authentication exchange. If we can, I'd be inclined to goose
it up to 128K or so. Given Chris' point that should be plenty,
so I don't feel a need to expose a knob.
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 по дате отправления: