Re: New predefined roles- 'pg_read/write_all_data'

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: gkokolatos(at)pm(dot)me
Cc: Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: New predefined roles- 'pg_read/write_all_data'
Date: 2021-04-01 20:00:06
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


* gkokolatos(at)pm(dot)me (gkokolatos(at)pm(dot)me) wrote:
> On Monday, November 23, 2020 11:31 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > - Anastasia Lubennikova (a(dot)lubennikova(at)postgrespro(dot)ru) wrote:
> >
> > > On 29.10.2020 17:19, Stephen Frost wrote:
> > >
> > > > - Georgios Kokolatos (gkokolatos(at)protonmail(dot)com) wrote:
> > > >
> > > > > this patch is in "Ready for committer" state and the Cfbot is happy.
> > > > > Glad that's still the case. :)
> > > >
> > > > > Is there any committer that is available for taking a look at it?
> > > > > If there aren't any objections or further comments, I'll take another
> > > > > look through it and will commit it during the upcoming CF.
> > >
> > > CFM reminder. Just in case you forgot about this thread)
> > > The commitfest is heading to the end. And there was a plenty of time for
> > > anyone to object.
> >
> > Thanks, I've not forgotten, but it's a bit complicated given that I've
> > another patch in progress to rename default roles to be predefined
> > roles which conflicts with this one. Hopefully we'll have a few
> > comments on that and I can get it committed and this one updated with
> > the new naming. I'd rather not commit this one and then immediately
> > commit changes over top of it.
> May I enquire about the status of the current?

The patch to rename default roles to predefined roles for v14 has gone
in, and so I've come back to this patch to add the
pg_read/write_all_data roles.

Having contemplated a bit further, I ended up deciding that it made more
sense for these predefined roles to *not* have BYPASSRLS, which gives
admins the flexibilty to choose if they actually want RLS to be
bypassed, or not, on the roles who they GRANT these roles to (if we just
always had bypassrls set, then they wouldn't have any choice but to
accept that, which doesn't seem very kind). I've updated the
documentation to make a note of that and to encourage admins who use
these roles to consider if they want to set BYPASSRLS on the actual
login role which they'll have to create in order to use these roles
(since they can't be used to login directly).

Updated patch attached. Will be playing with it a bit more but
generally feel like it's in pretty good shape. Unless there's anything
further on this, I'll likely commit it over the weekend.



Attachment Content-Type Size
pg_rorole_v3.patch text/x-diff 10.8 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2021-04-01 20:08:56 Re: pg_amcheck contrib application
Previous Message Stephen Frost 2021-04-01 19:33:45 Re: Default role -> Predefined role