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

Поиск
Список
Период
Сортировка
От Basha
Тема Re: [EXT]: Re: BUG #18604: Regression in PostgreSQL 16.4: pg_dump Prevents Essential System Table Modifications
Дата
Msg-id GV1P194MB2356014214267DDC379B98B3D89F2@GV1P194MB2356.EURP194.PROD.OUTLOOK.COM
обсуждение исходный текст
Ответ на Re: [EXT]: Re: BUG #18604: Regression in PostgreSQL 16.4: pg_dump Prevents Essential System Table Modifications  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-bugs
Дерево обсуждения
The code, provided is to recreate the problem if required. The access and barriers are taken care. Thanks,


From: Tom Lane <tgl@sss.pgh.pa.us>
Sent: Saturday, September 7, 2024 1:24:59 AM
To: Christophe Pettus <xof@thebuild.com>
Cc: Basha <Basha@maxcontact.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
 
[You don't often get email from tgl@sss.pgh.pa.us. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

Christophe Pettus <xof@thebuild.com> writes:
> You've really stepped outside what is considered supported behavior here.  That it worked at all was more accidental than a documented and supported feature.  Shadowing system catalogs with views *is* going to break things, and that `allow_system_table_mods` has that potential is documented.  I'm sure this is frustrating, but it's extremely unlikely that this will be considered a regression worth undoing a security fix for.

Indeed.  You might look into enforcing the restriction you want
by attaching an RLS policy to pg_database, instead of this hack.
Mind you, we are unlikely to consider that supported either if push
comes to shove.  But it would at least dodge your immediate problem.

(I'll just note that this implementation is full of holes anyway: you
didn't mark the view as a security_barrier view, and that treatment of
tableoid is hardly transparent.  And I do hope that your real recipe
includes revoking public read access on pg_database_catalog.)

                        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.

В списке pgsql-bugs по дате отправления: