| From: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
|---|---|
| To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
| Cc: | Michael Banck <mbanck(at)gmx(dot)net>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(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-03-06 01:14:46 |
| Message-ID: | CAOYmi+=47C8PEXZ8C9xxTRPtTevJgioQxJ3_vvd45rAQXPBy-Q@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Mar 5, 2024 at 1:51 PM Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:
> I don't have a strong opinion about making this configurable, but I do
> think we should consider making this a hash table so that we can set
> MAX_CONN_RECORDS much higher.
I'm curious why? It seems like the higher you make MAX_CONN_RECORDS,
the easier it is to put off the brute-force protection. (My assumption
is that anyone mounting a serious attack is not going to be doing this
from their own computer; they'll be doing it from many devices they
don't own -- a botnet, or a series of proxies, or something.)
--
Drive-by microreview -- auth_delay_cleanup_conn_record() has
> + port->remote_host[0] = '\0';
which doesn't seem right. I assume acr->remote_host was meant?
--Jacob
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Masahiko Sawada | 2024-03-06 01:30:17 | Re: Synchronizing slots from primary to standby |
| Previous Message | Bruce Momjian | 2024-03-06 01:12:18 | Re: Make query cancellation keys longer |