On Fri, Aug 28, 2020 at 2:43 PM Stephen Frost <sfrost@snowman.net> wrote:
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.
I think the core thing to remember here is that SQL permissions are always additive, that's what confuses some cases.
That is, REVOKE something FROM role only removes this particular additive permission. It doesn't make sure the role doesn't have the same permission *through some other means*.
Sometime it would be really useful to be able to do e.g. "DENY DELETE ON importanttable FROM sfrost", which would then override any DELETE permissions he'd be getting from anywhere else. To be able to say "everybody except x". But that's not something that's in SQL permissions AFAIK :)
> 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.
Yeah, for example another role might have a combination of read and write permissions, and those would then remain for the user if pg_read_all_data is removed.
