Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1smjGC-007qjb-LI for pgsql-bugs@arkaria.postgresql.org; Sat, 07 Sep 2024 00:25:04 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1smjGB-006goA-3l for pgsql-bugs@arkaria.postgresql.org; Sat, 07 Sep 2024 00:25:03 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1smjGA-006gjO-P8 for pgsql-bugs@lists.postgresql.org; Sat, 07 Sep 2024 00:25:03 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1smjG8-000W84-MG for pgsql-bugs@lists.postgresql.org; Sat, 07 Sep 2024 00:25:01 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 4870OxkW2398397; Fri, 6 Sep 2024 20:24:59 -0400 From: Tom Lane To: Christophe Pettus cc: Basha , PostgreSQL Bug List Subject: Re: [EXT]: Re: BUG #18604: Regression in PostgreSQL 16.4: pg_dump Prevents Essential System Table Modifications In-reply-to: <183A6734-06B2-48E9-A5C9-235EF87B0DFB@thebuild.com> References: <18604-04d64b68e981ced6@postgresql.org> <3B462E2E-88B6-43B9-943F-90E883D33357@thebuild.com> <183A6734-06B2-48E9-A5C9-235EF87B0DFB@thebuild.com> Comments: In-reply-to Christophe Pettus message dated "Fri, 06 Sep 2024 14:24:36 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2398395.1725668699.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Fri, 06 Sep 2024 20:24:59 -0400 Message-ID: <2398396.1725668699@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Christophe Pettus writes: > You've really stepped outside what is considered supported behavior here= . That it worked at all was more accidental than a documented and support= ed feature. Shadowing system catalogs with views *is* going to break thin= gs, 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 b= e 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