Re: [EXT]: Re: BUG #18604: Regression in PostgreSQL 16.4: pg_dump Prevents Essential System Table Modifications
Tom Lane <tgl@sss.pgh.pa.us>
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>
Date: 2024-09-07T15:43:13Z
Lists: pgsql-bugs
"David G. Johnston" <david.g.johnston@gmail.com> writes: > That said, I’d need to go back and see the arguments for why we don’t 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