| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
| Cc: | Joe Conway <mail(at)joeconway(dot)com>, Christophe Pettus <xof(at)thebuild(dot)com>, 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 15:43:13 |
| Message-ID: | 2504377.1725723793@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Basha | 2024-09-07 16:03:37 | RE: [EXT]: Re: BUG #18604: Regression in PostgreSQL 16.4: pg_dump Prevents Essential System Table Modifications |
| Previous Message | Tom Lane | 2024-09-07 15:28:54 | Re: [EXT]: Re: BUG #18604: Regression in PostgreSQL 16.4: pg_dump Prevents Essential System Table Modifications |