Re: [EXT]: Re: BUG #18604: Regression in PostgreSQL 16.4: pg_dump Prevents Essential System Table Modifications - Mailing list pgsql-bugs
| From | Basha |
|---|---|
| Subject | Re: [EXT]: Re: BUG #18604: Regression in PostgreSQL 16.4: pg_dump Prevents Essential System Table Modifications |
| Date | |
| Msg-id | GV1P194MB235610E122081099FBC480ECD89E2@GV1P194MB2356.EURP194.PROD.OUTLOOK.COM Whole thread Raw |
| In response to | Re: [EXT]: Re: BUG #18604: Regression in PostgreSQL 16.4: pg_dump Prevents Essential System Table Modifications (Christophe Pettus <xof@thebuild.com>) |
| List | pgsql-bugs |
Thank you for your response and for acknowledging the complexities of our use case.
We fully appreciate the importance of the security fix and the need to protect against unauthorized code execution. However, this change has left us in a challenging position.
If shadowing system catalogs via views is not a recommended path, we would be grateful for guidance on alternative approaches to achieve the same result—restricting visibility of databases in a multi-tenant environment while maintaining essential operations like backups. Specifically, is there a supported way to enforce database isolation at the system catalog level, or is there a possibility of introducing a more granular control over pg_dump in such cases?
We remain open to adjusting our approach if a safer, supported solution exists.
Thanks,
Basha
From: Christophe Pettus <xof@thebuild.com>
Sent: Friday, September 6, 2024 10:24:36 PM
To: Basha <Basha@maxcontact.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
Sent: Friday, September 6, 2024 10:24:36 PM
To: Basha <Basha@maxcontact.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
On Sep 6, 2024, at 13:46, Basha <Basha@maxcontact.com> wrote:
> Step 2:
> ALTER TABLE pg_catalog.pg_database RENAME TO pg_database_catalog;
>
>
> ALTER TABLE pg_catalog.pg_database_catalog
> OWNER TO postgres;
>
> Step3:
>
> CREATE OR REPLACE VIEW pg_catalog.pg_database
> AS
> SELECT oid,
> datname,
> datdba,
> encoding,
> datlocprovider,
> datistemplate,
> datallowconn,
> datconnlimit,
> datfrozenxid,
> datminmxid,
> dattablespace,
> datcollate,
> datctype,
> daticulocale,
> daticurules,
> datcollversion,
> datacl,
> 1262::oid AS tableoid
> FROM pg_database_catalog
> WHERE 1 = 1 AND has_database_privilege(oid, 'connect'::text);
>
>
> ALTER TABLE pg_catalog.pg_database
> OWNER TO postgres;
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.
> Step 2:
> ALTER TABLE pg_catalog.pg_database RENAME TO pg_database_catalog;
>
>
> ALTER TABLE pg_catalog.pg_database_catalog
> OWNER TO postgres;
>
> Step3:
>
> CREATE OR REPLACE VIEW pg_catalog.pg_database
> AS
> SELECT oid,
> datname,
> datdba,
> encoding,
> datlocprovider,
> datistemplate,
> datallowconn,
> datconnlimit,
> datfrozenxid,
> datminmxid,
> dattablespace,
> datcollate,
> datctype,
> daticulocale,
> daticurules,
> datcollversion,
> datacl,
> 1262::oid AS tableoid
> FROM pg_database_catalog
> WHERE 1 = 1 AND has_database_privilege(oid, 'connect'::text);
>
>
> ALTER TABLE pg_catalog.pg_database
> OWNER TO postgres;
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.
pgsql-bugs by date: