From: | Michael Banck <mbanck(at)gmx(dot)net> |
---|---|
To: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
Cc: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, Abhijit Menon-Sen <ams(at)toroid(dot)org>, pgsql-hackers(at)lists(dot)postgresql(dot)org, 成之焕 <zhcheng(at)ceresdata(dot)com> |
Subject: | Re: [PATCH] Exponential backoff for auth_delay |
Date: | 2024-04-07 07:43:39 |
Message-ID: | 66124eab.500a0220.47342.091b@mx.google.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On Wed, Mar 20, 2024 at 11:22:12PM +0100, Daniel Gustafsson wrote:
> > On 20 Mar 2024, at 22:21, Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> wrote:
> >
> > On Wed, Mar 20, 2024 at 2:15 PM Jacob Champion
> > <jacob(dot)champion(at)enterprisedb(dot)com> wrote:
> >> I think solutions for case 1 and case 2 are necessarily at odds under
> >> the current design, if auth_delay relies on slot exhaustion to do its
> >> work effectively. Weakening that on purpose doesn't make much sense to
> >> me; if a DBA is uncomfortable with the DoS implications then I'd argue
> >> they need a different solution. (Which we could theoretically
> >> implement, but it's not my intention to sign you up for that. :D )
> >
> > The thread got quiet, and I'm nervous that I squashed it unintentionally. :/
> >
> > Is there consensus on whether the backoff is useful, even without the
> > host tracking? (Or, alternatively, is the host tracking helpful in a
> > way I'm not seeing?) Failing those, is there a way forward that could
> > make it useful in the future?
>
> I actually wrote more or less the same patch with rudimentary attacker
> fingerprinting, and after some off-list discussion decided to abandon it for
> the reasons discussed in this thread. It's unlikely to protect against the
> attackers we wan't to protect the cluster against since they won't wait for the
> delay anyways.
I have marked the patch "Returned with Feedback" now. Maybe I will get
back to this for v18, but it was clearly not ready for v17.
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Nazir Bilal Yavuz | 2024-04-07 08:26:34 | Re: Change prefetch and read strategies to use range in pg_prewarm ... and raise a question about posix_fadvise WILLNEED |
Previous Message | Andres Freund | 2024-04-07 07:30:06 | Re: Improve heapgetpage() performance, overhead from serializable |