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