Date: Mon, 30 Jul 2018 19:21:31 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
Cc: 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
Message-ID: <20180730102131.GC2878@paquier.xyz>
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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="ey/N+yb7u/X9mFhi"
Content-Disposition: inline
In-Reply-To: <20180730.175354.32712514.horiguchi.kyotaro@lab.ntt.co.jp>
Precedence: bulk


--ey/N+yb7u/X9mFhi
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

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

--ey/N+yb7u/X9mFhi
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAlte5qsACgkQnvQgOdby
QH3nSxAAoHM/M6+/8wleBqSIKfL4AA6tFSO/7N6lq0e+6vuwNMg+S8lS/+dbSdGe
QI9218vNioJ1hdpVIcUJPslf+lgaSQj7NArJ004Rb6quBzfyn1ZUs/KVO9AsW+c9
vDnATuztYzi03LrfECcmx5/Pmmq7ak9tY9TAsJyAlUNFTXJPp27TMwkEIi3rMZgD
/0iEdzgac/bWLaPtTcimBBAKH+yr1PIUCKXwFViFsDpjdDOpjltM8/SeOdfL1bUG
ru3FVY+CpQmCYkHGDsKDfc6lRxsjncm/U18OAXbxm+dN4TollbXa0UhGZdyMc/np
vBo7T9hzRaDZUfGbea5SFF1o+RuYTMpBWG+I5GQZ0iZMegfANc/xTHUWL+nskZT0
nGA24s8dxEtvaySf36VKu0ytgf6SDuE0DVZDBCgzcXt2Q74UFBxBXT7wboIkEZH8
xLp9yGQRVt2GxOXrfkBub4TtLmBE/cY8LNNubsFeIWS5cOpklg+EEk+iwaE71ZBf
vjG+ndJjBRkfjV/kGWWoqtGHaC0ZLCyFPFdiJZWJ8Bnm1J63IOwW3F0wA8o5WCTI
jMr4RHhT+1jyLt+Yu1R2nfF64yFLyHR24MgAyZzyE7QfCnuEn5Vvg9MSvrNgLpso
gBrkNwOgUuRj/CJkC1f3TDkbbFN+wA6ypmuDXN8peD7ZVX2hdKo=
=YMcX
-----END PGP SIGNATURE-----

--ey/N+yb7u/X9mFhi--