From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
---|---|
To: | Fabrízio de Royes Mello <fabriziomello(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Removing the fixed-size buffer restriction in hba.c |
Date: | 2023-07-24 22:58:31 |
Message-ID: | 20230724225831.GA2550571@nathanxps13 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jul 24, 2023 at 03:07:07PM -0300, Fabrízio de Royes Mello wrote:
> On Mon, Jul 24, 2023 at 2:53 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>
>> We got a complaint at [1] about how a not-so-unreasonable LDAP
>> configuration can hit the "authentication file token too long,
>> skipping" error case in hba.c's next_token(). I think we've
>> seen similar complaints before, although a desultory archives
>> search didn't turn one up.
>>
>> A minimum-change response would be to increase the MAX_TOKEN
>> constant from 256 to (say) 1K or 10K. But it wouldn't be all
>> that hard to replace the fixed-size buffer with a StringInfo,
>> as attached.
>>
>
> +1 for replacing it with StringInfo. And the patch LGTM!
I'd suggest noting that next_token() clears buf, but otherwise it looks
reasonable to me, too.
>> Given the infrequency of complaints, I'm inclined to apply
>> the more thorough fix only in HEAD, and to just raise MAX_TOKEN
>> in the back branches. Thoughts?
>>
>
> It makes sense to change it only in HEAD.
I wouldn't be opposed to back-patching the more thorough fix, but I don't
feel too strongly about it.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2023-07-24 23:02:36 | Re: [PATCH] Check more invariants during syscache initialization |
Previous Message | Michael Paquier | 2023-07-24 22:46:52 | Re: [BUG] Crash on pgbench initialization. |