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 20200828124303.GW29590@tamriel.snowman.net
Whole thread Raw
In response to Re: New default role- 'pg_read_all_data'  (Georgios Kokolatos <gkokolatos@protonmail.com>)
Responses Re: New default role- 'pg_read_all_data'
Re: New default role- 'pg_read_all_data'
Re: New default role- 'pg_read_all_data'
List pgsql-hackers
Greetings,

* Georgios Kokolatos (gkokolatos@protonmail.com) wrote:
> The patch seems to be implementing a useful and requested feature.
> The patch applies cleanly and passes the basic regress tests. Also the commitfest bot is happy.
>
> A first pass at the code, has not revealed any worthwhile comments.
> Please allow me for a second and more thorough pass. The commitfest has hardly started after all.

Great, thanks!

> Also allow me a series of genuine questions:
>
> What would the behaviour be with REVOKE?
> In a sequence similar to:
> GRANT ALL ON ...

GRANT ALL would be independently GRANT'ing rights to some role and
therefore unrelated.

> REVOKE pg_read_all_data FROM ...

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?

I'm not sure what's being asked here.

> Does the above scenario even make sense?

I definitely believe it makes sense for a given role/user to be a member
of pg_read_all_data and to be a member of other roles, or to have other
privileges GRANT'd directly to them.

Thanks,

Stephen

Attachment

pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: New default role- 'pg_read_all_data'
Next
From: Jakub Wartak
Date:
Subject: Re: Handing off SLRU fsyncs to the checkpointer