From: Stephen Frost <sfrost@snowman.net>
To: Magnus Hagander <magnus@hagander.net>
Cc: PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Subject: Re: New default role- 'pg_read_all_data'
Date: Fri, 28 Aug 2020 09:26:45 -0400
Message-ID: <20200828132645.GZ29590@tamriel.snowman.net> (raw)
In-Reply-To: <CABUevEx5akfNeSrHsinCRWfXzSYFNRTnBc4vHKMgum8hLrr=yg@mail.gmail.com>
References: <20200828003023.GU29590@tamriel.snowman.net>
<CABUevEy9QAnx5h_BmSk4j6K9AfS9=co15RUFda0kknMHO9NJOg@mail.gmail.com>
<20200828123847.GV29590@tamriel.snowman.net>
<CABUevEx5akfNeSrHsinCRWfXzSYFNRTnBc4vHKMgum8hLrr=yg@mail.gmail.com>
Greetings,
* Magnus Hagander (magnus@hagander.net) wrote:
> On Fri, Aug 28, 2020 at 2:38 PM Stephen Frost <sfrost@snowman.net> wrote:
> > * Magnus Hagander (magnus@hagander.net) wrote:
> > > Without having actually looked at the code, definite +1 for this feature.
> > > It's much requested...
> >
> > Thanks.
> >
> > > But, should we also have a pg_write_all_data to go along with it?
> >
> > Perhaps, but could certainly be a different patch, and it'd need to be
> > better defined, it seems to me... read_all is pretty straight-forward
> > (the general goal being "make pg_dumpall/pg_dump work"), what would
> > write mean? INSERT? DELETE? TRUNCATE? ALTER TABLE? System catalogs?
>
> Well, it's pg_write_all_*data*, so it certainly wouldn't be alter table or
> system catalogs.
>
> I'd say insert/update/delete yes.
>
> TRUNCATE is always an outlier.Given it's generally classified as DDL, I
> wouldn't include it.
Alright, that seems like it'd be pretty easy. We already have a check
in pg_class_aclmask to disallow modification of system catalogs w/o
being a superuser, so we should be alright to add a similar check for
insert/update/delete just below where I added the SELECT check.
> > Doesn't seem like you could just declare it to be 'allow pg_restore'
> > either, as that might include creating untrusted functions, et al.
>
> No definitely not. That wouldn't be the usecase at all :)
Good. :)
> (and fwiw to me the main use case for read_all_data also isn't pg_dump,
> because most people using pg_dump are already db owner or higher in my
> experience. But it is nice that it helps with that too)
Glad to have confirmation that there's other use-cases this helps with.
I'll post an updated patch with that added in a day or two.
Thanks,
Stephen
Attachments:
signature.asc (application/pgp-signature, 818B) download
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-hackers@postgresql.org
Cc: sfrost@snowman.net, magnus@hagander.net, pgsql-hackers@lists.postgresql.org
Subject: Re: New default role- 'pg_read_all_data'
In-Reply-To: <20200828132645.GZ29590@tamriel.snowman.net>
* 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