Horton

Re: BUG #15182: Canceling authentication due to timeout aka Denial of Service Attack

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>, "Bossart, Nathan" <bossartn@amazon.com>, Andres Freund <andres@anarazel.de>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Jeremy Schneider <schnjere@amazon.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, "Albin, Lloyd P" <lalbin@scharp.org>
Date: 2018-07-31T14:34:57Z
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 →

  1. Improve VACUUM and ANALYZE by avoiding early lock queue

  2. Improve TRUNCATE by avoiding early lock queue

  3. Restrict access to reindex of shared catalogs for non-privileged users

  4. Improve behavior of concurrent CLUSTER.

On Mon, Jul 30, 2018 at 6:21 AM, Michael Paquier <michael@paquier.xyz> wrote:
> On Mon, Jul 30, 2018 at 05:53:54PM +0900, Kyotaro HORIGUCHI wrote:
>> I feel that just being a database owner doesn't justify to cause
>> this problem innocently. Catalog owner is also doubious but we
>> can carefully configure the ownerships to avoid the problem since
>> only superuser can change it. So I vote +1 for the revised patch.
>
> Thanks for the review.  Yes that sucks that being just a database or a
> schema owner allows such a user to take an exclusive lock on shared
> catalogs.  Please note that depending on the order of the relations,
> authentication may or may not be blocked depending on what kind of locks
> the second session takes.

Just as a general statement, I don't think we should, as part of a
patch for the issue discussed on this thread, make any changes AT ALL
to who has permission to perform which operations.  We *certainly*
should not back-patch such changes, but we really also should not make
them on master unless they are discussed on a separate thread with a
clear subject line and agreed by a clear consensus.

This patch should only be about detecting cases where we lack
permission earlier, before we try to acquire a lock.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company