Re: New default role- 'pg_read_all_data' - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: New default role- 'pg_read_all_data'
Date
Msg-id 20200828125411.GX29590@tamriel.snowman.net
Whole thread Raw
In response to Re: New default role- 'pg_read_all_data'  (Isaac Morland <isaac.morland@gmail.com>)
Responses Re: New default role- 'pg_read_all_data'  (Isaac Morland <isaac.morland@gmail.com>)
List pgsql-hackers
Greetings,

* Isaac Morland (isaac.morland@gmail.com) wrote:
> On Fri, 28 Aug 2020 at 08:43, Stephen Frost <sfrost@snowman.net> wrote:
> > This would simply REVOKE that role from the user.  Privileges
> > independently GRANT'd directly to the user wouldn't be affected.  Nor
> > would other role membership.
> >
> > > What privileges would the user be left with? Would it be possible to end
> > up in the same privilege only with a GRANT command?
>
> What about:
>
> REVOKE SELECT ON [table] FROM pg_read_all_data;

Wouldn't have any effect, and I think that's correct.

> I guess what I’m really asking is whether pg_read_all_data is automatically
> granted SELECT on all newly-created relations, or if the permission
> checking system always returns TRUE when asked if pg_read_all_data can
> select from a relation? I’m guessing it’s the latter so that it would be
> ineffective to revoke select privilege as I think this is more useful, but
> I’d like to be sure and the documentation should be explicit on this point.

Yes, it's the latter.  I'm not really sure about the documentation
change you're contemplating- have a specific suggestion?

Thanks,

Stephen

Attachment

pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: New default role- 'pg_read_all_data'
Next
From: gkokolatos@pm.me
Date:
Subject: Re: New default role- 'pg_read_all_data'