Re: BUG #15182: Canceling authentication due to timeout aka Denial of Service Attack
Jeff Janes <jeff.janes@gmail.com>
From: Jeff Janes <jeff.janes@gmail.com>
To: Marko Tiikkaja <marko@joh.to>
Cc: Jeremy Schneider <schnjere@amazon.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>, "Albin,
Lloyd P" <lalbin@scharp.org>
Date: 2018-07-23T20:14:40Z
Lists: pgsql-bugs, pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Improve VACUUM and ANALYZE by avoiding early lock queue
- a556549d7e6d 12.0 landed
-
Improve TRUNCATE by avoiding early lock queue
- f841ceb26d70 12.0 landed
-
Restrict access to reindex of shared catalogs for non-privileged users
- 87330e21c327 11.0 landed
- 661dd23950f2 12.0 landed
-
Improve behavior of concurrent CLUSTER.
- cbe24a6dd8fb 9.2.0 cited
On Fri, Jul 20, 2018 at 5:56 PM, Marko Tiikkaja <marko@joh.to> wrote: > On Fri, Jul 20, 2018 at 2:17 AM, Jeremy Schneider <schnjere@amazon.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