From: Michael Paquier <michael@paquier.xyz>
To: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
Cc: bossartn@amazon.com
Cc: andres@anarazel.de
Cc: pgsql-hackers@lists.postgresql.org
Cc: robertmhaas@gmail.com
Cc: schnjere@amazon.com
Cc: pgsql-hackers@postgresql.org
Cc: lalbin@scharp.org
Subject: Re: BUG #15182: Canceling authentication due to timeout aka Denial of Service Attack
Date: Mon, 30 Jul 2018 19:21:31 +0900
Message-ID: <20180730102131.GC2878@paquier.xyz> (raw)
In-Reply-To: <20180730.175354.32712514.horiguchi.kyotaro@lab.ntt.co.jp>
References: <20180728001012.GC1882@paquier.xyz>
<6D3CBDB6-C358-49F0-8D00-32E58AD2D3D3@amazon.com>
<20180730003422.GA2878@paquier.xyz>
<20180730.175354.32712514.horiguchi.kyotaro@lab.ntt.co.jp>
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.
> | Parameters
> ...
> | SYSTEM
> | Recreate all indexes on system catalogs within the current
> | database. *Indexes on shared system catalogs are included*.
> | Indexes on user tables are not processed. This form
> | of REINDEX cannot be executed inside a transaction block.
This looks correct to me, shared catalogs are included, and the "notes"
section clealy mentions that being an owner of the shared catalog is
required.
> This apparently changes the documented behavior and the problem
> seems to be a result of a rather malicious/intentional
> combination of operatoins (especially named vacuum on a shared
> catalog). I vote -0.5 to backpatch unless we categorize this as a
> security issue.
Ask that to any vendors doing shared hosting of Postgres :)
A backpatch looks like the correct course of events to me. Anybody here
is free to express his/her concerns of course.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (832B, ../20180730102131.GC2878@paquier.xyz/2-signature.asc)
download
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: michael@paquier.xyz, horiguchi.kyotaro@lab.ntt.co.jp, bossartn@amazon.com, andres@anarazel.de, pgsql-hackers@lists.postgresql.org, robertmhaas@gmail.com, schnjere@amazon.com, pgsql-hackers@postgresql.org, lalbin@scharp.org
Subject: Re: BUG #15182: Canceling authentication due to timeout aka Denial of Service Attack
In-Reply-To: <20180730102131.GC2878@paquier.xyz>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox