From: Tom Lane <tgl@sss.pgh.pa.us>
To: "Imseih (AWS), Sami" <simseih@amazon.com>
cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: [BUG] autovacuum may skip tables when session_authorization/role is set on database
In-reply-to: <4814073F-6387-4873-8B8E-4D6A7390DEC7@amazon.com>
References: <4814073F-6387-4873-8B8E-4D6A7390DEC7@amazon.com>
Comments: In-reply-to "Imseih (AWS), Sami" <simseih@amazon.com>
	message dated "Wed, 13 Dec 2023 20:42:45 +0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2660031.1702502302.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Wed, 13 Dec 2023 16:18:22 -0500
Message-ID: <2660032.1702502302@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/2660032.1702502302%40sss.pgh.pa.us>
Precedence: bulk

"Imseih (AWS), Sami" <simseih@amazon.com> writes:
> A recent case in the field in which a database session_authorization is
> altered to a non-superuser, non-owner of tables via alter database .. se=
t session_authorization ..
> caused autovacuum to skip tables.

That seems like an extremely not-bright idea.  What is the actual
use case for such a setting?  Doesn't it risk security problems?

> Attached is a repro and a patch which sets the session user to the BOOTS=
TRAP superuser
> at the start of the autovac worker.

I'm rather unimpressed by this proposal, first because there are
probably ten other ways to break autovac with ill-considered settings,
and second because if we do want to consider this a supported case,
what about other background processes?  They'd likely have issues
as well.

			regards, tom lane