From: Tom Lane <tgl@sss.pgh.pa.us>
To: "David G. Johnston" <david.g.johnston@gmail.com>
cc: Joe Conway <mail@joeconway.com>, Christophe Pettus <xof@thebuild.com>,
        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
In-reply-to: 
 <CAKFQuwb+=niX=uqoX2EuOX_uSfiCuOv+cAXs1wW8vE0GC-wanw@mail.gmail.com>
References: <18604-04d64b68e981ced6@postgresql.org>
 <3B462E2E-88B6-43B9-943F-90E883D33357@thebuild.com>
 <GV1P194MB2356E0520E83B40CE57D4D2FD89E2@GV1P194MB2356.EURP194.PROD.OUTLOOK.COM>
 <183A6734-06B2-48E9-A5C9-235EF87B0DFB@thebuild.com>
 <GV1P194MB235610E122081099FBC480ECD89E2@GV1P194MB2356.EURP194.PROD.OUTLOOK.COM>
 <6860E1BC-DA5A-4576-9FB6-35ED31E6F017@thebuild.com>
 <GV1P194MB2356082D55A66B1F659F1AA5D89F2@GV1P194MB2356.EURP194.PROD.OUTLOOK.COM>
 <73AD2F56-1009-49C7-8752-39C45325A9BB@thebuild.com>
 <GV1P194MB2356E46170B9C91E45E6987FD89F2@GV1P194MB2356.EURP194.PROD.OUTLOOK.COM>
 <01CF2C94-D153-4687-B2EF-EF4B4B1890DF@thebuild.com>
 <2410942.1725675471@sss.pgh.pa.us>
 <8D1E6C08-1C4B-4056-846F-C33C0056249E@thebuild.com>
 <172a934d-6a5d-4c57-9935-43862025b842@joeconway.com>
 <CAKFQuwb+=niX=uqoX2EuOX_uSfiCuOv+cAXs1wW8vE0GC-wanw@mail.gmail.com>
Comments: In-reply-to "David G. Johnston" <david.g.johnston@gmail.com>
	message dated "Sat, 07 Sep 2024 07:38:35 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <2504376.1725723793.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Sat, 07 Sep 2024 11:43:13 -0400
Message-ID: <2504377.1725723793@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2504377.1725723793%40sss.pgh.pa.us>
Precedence: bulk

"David G. Johnston" <david.g.johnston@gmail.com> writes:
> That said, I=E2=80=99d need to go back and see the arguments for why we =
don=E2=80=99t just
> filter the list of globals to whatever the logged in role is capable of
> using.

Filtering roles this way would require a whole lot more thought,
and I doubt you could get away with just hiding roles that the current
user can't become.  As an example, it would be sad if \df+ stopped
showing any built-in functions because it failed to join their
pg_proc.proowner to pg_roles.

In the particular case of \df+, it looks like it'd actually continue
to work because it goes through pg_get_userbyid() which wouldn't pay
any attention to RLS anyway.  ACL display is another obvious place
that would leak role names.  So there's also a boatload of questions
around leakage of the supposedly hidden roles.

pg_database is not nearly as entwined with the local catalogs, so
I think what I suggested would be enough in practice for that.

			regards, tom lane