pg.ddx.io  pgsql-bugs@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: David G. Johnston <david.g.johnston@gmail.com>
Cc: Joe Conway <mail@joeconway.com>
Cc: Christophe Pettus <xof@thebuild.com>
Cc: Basha <Basha@maxcontact.com>
Cc: 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
Date: Sat, 07 Sep 2024 11:43:13 -0400
Message-ID: <2504377.1725723793@sss.pgh.pa.us> (raw)
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>

"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





view thread (30+ messages)  latest in thread

Message-ID: <2504377.1725723793@sss.pgh.pa.us>
Permalink:  ../2504377.1725723793@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/2504377.1725723793@sss.pgh.pa.us

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-bugs@postgresql.org
  Cc: tgl@sss.pgh.pa.us, david.g.johnston@gmail.com, mail@joeconway.com, xof@thebuild.com, Basha@maxcontact.com, 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: <2504377.1725723793@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox