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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Christophe Pettus <xof(at)thebuild(dot)com>
Cc: Basha <Basha(at)maxcontact(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
Date: 2024-09-07 00:24:59
Message-ID: 2398396.1725668699@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Christophe Pettus <xof(at)thebuild(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Christophe Pettus 2024-09-07 00:29:52 Re: [EXT]: Re: BUG #18604: Regression in PostgreSQL 16.4: pg_dump Prevents Essential System Table Modifications
Previous Message Basha 2024-09-06 23:44:43 Re: [EXT]: Re: BUG #18604: Regression in PostgreSQL 16.4: pg_dump Prevents Essential System Table Modifications