| From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
|---|---|
| To: | Marko Tiikkaja <marko(at)joh(dot)to> |
| Cc: | Jeremy Schneider <schnjere(at)amazon(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, "Albin, Lloyd P" <lalbin(at)scharp(dot)org> |
| Subject: | Re: BUG #15182: Canceling authentication due to timeout aka Denial of Service Attack |
| Date: | 2018-07-23 20:14:40 |
| Message-ID: | CAMkU=1zKxAHhrrmgPMxdDPvdmeaKKqk7Bma=oQ0=QKAfhoH8Gg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs pgsql-hackers |
On Fri, Jul 20, 2018 at 5:56 PM, Marko Tiikkaja <marko(at)joh(dot)to> wrote:
> On Fri, Jul 20, 2018 at 2:17 AM, Jeremy Schneider <schnjere(at)amazon(dot)com>
> wrote:
>
>> I'd like to bump this old bug that Lloyd filed for more discussion. It
>> seems serious enough to me that we should at least talk about it.
>>
>> Anyone with simply the login privilege and the ability to run SQL can
>> instantly block all new incoming connections to a DB including new
>> superuser connections.
>>
>
> So.. don't VACUUM FULL pg_authid without lock_timeout?
>
That's like saying the solution to a security hole is for no one to attempt
to exploit it.
Note that you do not need to have permissions to do the vacuum full. This
works merely from the attempt to do so, before the permissions are checked.
Cheers,
Jeff
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2018-07-24 04:14:03 | Re: BUG #15182: Canceling authentication due to timeout aka Denial of Service Attack |
| Previous Message | Moshe Jacobson | 2018-07-23 19:13:41 | Re: pg_restore: All GRANTs on table fail when any one role is missing |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2018-07-23 21:04:21 | Re: Stored procedures and out parameters |
| Previous Message | Andres Freund | 2018-07-23 19:55:48 | Re: Missing pg_control crashes postmaster |