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: Christophe Pettus <xof@thebuild.com>
Cc: Joe Conway <mail@joeconway.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 14:21:33 -0400
Message-ID: <2522013.1725733293@sss.pgh.pa.us> (raw)
In-Reply-To: <GV1P194MB2356E8A0BCE25A4EB08AF8B7D89F2@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>
	<2514770.1725729411@sss.pgh.pa.us>
	<831E0C7F-4E37-45F9-AA05-04648077FD8D@thebuild.com>
	<GV1P194MB2356E! 8A0BCE25A4EB08AF8B7D89F2@GV1P194MB2356.EURP194.PROD.OUTLOOK.COM>

Basha <Basha@maxcontact.com> writes:
> The fix in PG16.4, entirely prevents changes to pg_database, Is
> there any possibility of a more targeted approach.

If we allow pg_database to be replaced by a view, we have the same
hazard that the security patch means to fix: namely that the view
might be hostile, or even just that it might innocently lie to us
resulting in incorrect pg_dump output.  I'm uninterested in poking
a hole in that security defense.

I don't think we've ended the discussion on whether to remove the
check that's preventing using RLS instead.  But even if we choose
to do that, you're still depending on something that's not
supported and might break again in future.  To be absolutely
clear: *nothing* you might use allow_system_table_mods to do
is considered supported for production purposes, and we will not
apologize for breaking it.

You really ought to think about how badly do you need to hide the
existence of other databases.  It seems like a mighty low-priority
requirement from here, especially if you can't also hide the existence
of other roles.

			regards, tom lane





view thread (30+ messages)  latest in thread

Message-ID: <2522013.1725733293@sss.pgh.pa.us>
Permalink:  ../2522013.1725733293@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/2522013.1725733293@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, xof@thebuild.com, mail@joeconway.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: <2522013.1725733293@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