-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement GRANT TO PUBLIC for all supported object types #106
Conversation
Just some thoughts- Based on the syntax of GRANT, would it make more sense to trigger on Should the comparison for |
https://docs.aws.amazon.com/redshift/latest/dg/r_GRANT.html PUBLIC As it represents a group I think this implementation is correct and using USER=PUBLIC might be misleading and not consistent with PostgreSQL and Redshift implementation and naming. With RBAC implementation in provider this will be also useful. |
The postgresql provider does this as a part of the role resource - which seems to more or less approximate a user. I'm really not arguing for either way being right, just wanted to point it out - the code looked a little awkward. |
@mtesch-um thank you for the feedback. I decided to use a group as the GRANT documentation for both PostgreSQL and Redshift says:
The code would not really change whether it will be a user or group. It's due to how the permissions for PUBLIC are represented in Redshift. If you take a look at
I had to modify the query to avoid accidentally catching users/groups ACLs. I tried fitting it to existing queries but that was just causing more problems. Vanilla PostgreSQL is different in this case as it does not have a separation for users and groups in newer versions, where a role combines both (can be given a password to imitate a user and can be assigned other roles to form "groups"). Redshift is slowly heading that way too with RBAC. |
The PR adds implementation of
GRANT ... TO PUBLIC
. Example usage in resource:Fixes #61