From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Georgios Kokolatos <gkokolatos(at)protonmail(dot)com> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: New default role- 'pg_read_all_data' |
Date: | 2020-08-28 12:43:03 |
Message-ID: | 20200828124303.GW29590@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greetings,
* Georgios Kokolatos (gkokolatos(at)protonmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Jakub Wartak | 2020-08-28 12:43:52 | Re: Handing off SLRU fsyncs to the checkpointer |
Previous Message | Stephen Frost | 2020-08-28 12:38:48 | Re: New default role- 'pg_read_all_data' |