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

On Mon, Jul 30, 2018 at 6:21 AM, Michael Paquier <michael(at)paquier(dot)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