Re: [EXT]: Re: BUG #18604: Regression in PostgreSQL 16.4: pg_dump Prevents Essential System Table Modifications

Thank you for considering the RLS. Which would really help in solving.

All Iam looking is some kind of solution to the issue.

With regards to the roles , I have added the below into the view pg_catalog.pg_roles.

WHERE pg_has_role(CURRENT_USER, pg_authid.oid, 'member'::text) OR (pg_authid.rolname = ANY (ARRAY['postgres'::name);

This way, it will only show the roles they are member of. This makes sure it doesn't show other db roles.

Thank you,
Basha

Sent from Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Sent: Saturday, September 7, 2024 7:21:33 PM
To: Basha <Basha(at)maxcontact(dot)com>
Cc: Christophe Pettus <xof(at)thebuild(dot)com>; Joe Conway <mail(at)joeconway(dot)com>; PostgreSQL Bug List <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: [EXT]: Re: BUG #18604: Regression in PostgreSQL 16.4: pg_dump Prevents Essential System Table Modifications

Basha <Basha(at)maxcontact(dot)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
MaxContact is a trading style of Trivoni Software Limited. Registration Number: England 09816677. Registered Office: City View House, 5 Union Street, Ardwick, Manchester M12 4JD. This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom it is addressed. Any views or options presented are solely those of the author and do not necessarily represent those of Trivoni Software Limited. Internet communications are not secure and therefore Trivoni Software Limited does not accept legal responsibility for the contents of this message. If you are not the intended recipient, you are hereby notified that you have received this e-mail in error and that any use, disclosure, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. Trivoni Software Limited will not be liable for direct, special, indirect or consequential damage arising from alterations of the contents of this message by a third party or as a result of any VIRUS being passed on. Any pricing details or other offers delivered via e-mail are not binding. If appropriate, an official purchase order quotation confirming pricing and bearing an authorisation signature will be provided via Docusign on request. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail without taking any copies or forwarding it elsewhere.