From: Tom Lane <tgl@sss.pgh.pa.us>
To: Basha <Basha@maxcontact.com>
cc: Joe Conway <mail@joeconway.com>, Christophe Pettus <xof@thebuild.com>,
        PostgreSQL Bug List <pgsql-bugs@lists.postgresql.org>
Subject: Re: [EXT]: Re: BUG #18604: Regression in PostgreSQL 16.4: pg_dump
 Prevents Essential System Table Modifications
In-reply-to: 
 <GV1P194MB2356EC281D6CB132537B7DD6D89F2@GV1P194MB2356.EURP194.PROD.OUTLOOK.COM>
References: <18604-04d64b68e981ced6@postgresql.org>
 <3B462E2E-88B6-43B9-943F-90E883D33357@thebuild.com>
 <GV1P194MB2356E0520E83B40CE57D4D2FD89E2@GV1P194MB2356.EURP194.PROD.OUTLOOK.COM>
 <183A6734-06B2-48E9-A5C9-235EF87B0DFB@thebuild.com>
 <GV1P194MB235610E122081099FBC480ECD89E2@GV1P194MB2356.EURP194.PROD.OUTLOOK.COM>
 <6860E1BC-DA5A-4576-9FB6-35ED31E6F017@thebuild.com>
 <GV1P194MB2356082D55A66B1F659F1AA5D89F2@GV1P194MB2356.EURP194.PROD.OUTLOOK.COM>
 <73AD2F56-1009-49C7-8752-39C45325A9BB@thebuild.com>
 <GV1P194MB2356E46170B9C91E45E6987FD89F2@GV1P194MB2356.EURP194.PROD.OUTLOOK.COM>
 <01CF2C94-D153-4687-B2EF-EF4B4B1890DF@thebuild.com>
 <2410942.1725675471@sss.pgh.pa.us>
 <8D1E6C08-1C4B-4056-846F-C33C0056249E@thebuild.com>
 <172a934d-6a5d-4c57-9935-43862025b842@joeconway.com>
 <2503009.1725722934@sss.pgh.pa.us>
 <GV1P194MB2356EC281D6CB132537B7DD6D89F2@GV1P194MB2356.EURP194.PROD.OUTLOOK.COM>
Comments: In-reply-to Basha <Basha@maxcontact.com>
	message dated "Sat, 07 Sep 2024 16:03:37 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2514769.1725729411.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Sat, 07 Sep 2024 13:16:51 -0400
Message-ID: <2514770.1725729411@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2514770.1725729411%40sss.pgh.pa.us>
Precedence: bulk

Basha <Basha@maxcontact.com> writes:
> As suggested, tried creating the below RLS policy on the pg_database tab=
le. But seems it does not check for the connect permission.

[ pokes around... ]  Ah indeed, because check_enable_rls has a
hard-wired assumption that no built-in table has any RLS:

	/* Nothing to do for built-in relations */
	if (relid < (Oid) FirstNormalObjectId)
		return RLS_NONE;

I wonder if we should remove that?  It's only saving one syscache
lookup (and if we were hot about that, most of the callers have
an open Relation that could be passed).  I did check that this
policy works as-expected if that test is deleted.

Still, making such a change would amount to actively supporting RLS
on catalogs, rather than just a laissez-faire "you can use it if it
works" approach.  I'm not convinced we want to go there, because for
a lot of the catalogs there are going to be additional access pathways
such as I mentioned for roles.  I do not want to buy into those things
becoming arguable security bugs.  And I *definitely* don't want to try
to close off system accesses to catalogs based on RLS.

			regards, tom lane