BUG #18604: Regression in PostgreSQL 16.4: pg_dump Prevents Essential System Table Modifications

The following bug has been logged on the website:

Bug reference: 18604
Logged by: Aladin Basha
Email address: basha(at)maxcontact(dot)com
PostgreSQL version: 16.4
Operating system: Ubuntu 22.04.4 LTS
Description:

In PostgreSQL 16.4, the recent security enhancement introduced by the commit
"Prevent unauthorized code execution during pg_dump (Masahiko Sawada)" has
introduced unintended side effects that severely impact multi-tenant
database environments. Specifically, this change blocks modifications to
system tables, even when allow_system_table_mods is explicitly enabled.

Our multi-tenant architecture relies on modifying system tables to ensure
database isolation for each customer. Each customer is assigned a dedicated
database, and by modifying system tables, we restrict their visibility of
other databases. This is a critical component of our security model, where
each customer only sees their own database within tools like pgAdmin, which
query the pg_database table.

However, after the PostgreSQL 16.4 update, pg_dump now fails due to these
system table modifications, leaving us in a precarious position where
essential backups cannot be performed. This restriction appears to apply
globally, without any option to bypass or disable it, even when the system
table modification flag is set.

Expected Behavior:
The security feature should allow system table modifications when
allow_system_table_mods is enabled.

The restriction on pg_dump should be optional or configurable, particularly
for environments where system table modifications are an intentional and
controlled part of the setup.
Actual Behavior:

pg_dump refuses to work when system table modifications are in place, even
when allow_system_table_mods is enabled.
Impact:

Our multi-tenant environment, which relies heavily on system table
modifications for tenant isolation, is unable to use pg_dump to perform
backups, thus compromising data safety.

This issue severely disrupts the workflow of environments where customer
isolation through system table modification is critical, leaving us with no
viable alternative for backups or data visibility management.

We believe that the new security feature should allow for more flexibility,
especially in controlled environments where allow_system_table_mods is
explicitly enabled. It should either provide an option to override this
restriction in pg_dump, or respect the configuration settings that allow
system table modifications.

PostgreSQL Version: PostgreSQL 16.4

Steps to Reproduce:
Enable allow_system_table_mods = true.
Modify system tables (e.g., pg_database) to restrict visibility in a
multi-tenant setup.
Attempt to run pg_dump for backup purposes.
pg_dump fails due to the recent security restriction.

Suggested Resolution:
Introduce a configurable option in pg_dump to allow it to work with modified
system tables when allow_system_table_mods is enabled.

Adjust the security enhancement to respect environments where system table
modifications are a necessary feature, or provide a safe, configurable
bypass for such use cases.

Thank you for your attention to this matter. We look forward to a resolution
that ensures both security and flexibility for diverse PostgreSQL use cases.