pg.ddx.io  pgsql-bugs@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Basha <Basha@maxcontact.com>
Cc: Joe Conway <mail@joeconway.com>
Cc: Christophe Pettus <xof@thebuild.com>
Cc: 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
Date: Sat, 07 Sep 2024 13:16:51 -0400
Message-ID: <2514770.1725729411@sss.pgh.pa.us> (raw)
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>

Basha <Basha@maxcontact.com> writes:
> As suggested, tried creating the below RLS policy on the pg_database table. 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





view thread (30+ messages)  latest in thread

Message-ID: <2514770.1725729411@sss.pgh.pa.us>
Permalink:  ../2514770.1725729411@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/2514770.1725729411@sss.pgh.pa.us

 · 

reply
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: tgl@sss.pgh.pa.us, Basha@maxcontact.com, mail@joeconway.com, xof@thebuild.com, 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: <2514770.1725729411@sss.pgh.pa.us>

* 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