As per the recent discussion, since auditor is simply a read-only version of member, and global_auditor will be a read-only version of admin, it probably makes sense to roll these into their respective roles.
I'll look to update that as part of the next PR I put in
Hmmm, the more I think about it, the more I flip-flop on it
I think the readability of "rule:admin or rule:auditor" and "rule:admin or rule:member or rule:auditor" makes reading the rules easier, I know the general direction is to not have users modify them, but the way the access goes, the ones that are read-only calls would just need the additional or rule:auditor, I don't see a way to collapse those down any further. On writer calls, "rule:admin or rule:member" or just "rule:admin" seems the simplest. As for why we should be verbose about admin, it helps to show the difference in which calls are intended for admin-only vs regular members
Idk, I know we could collapse them down to a single rule that incorporates all of them like a rule:is_admin_or_member, but that seems to needlessly abstract it. Idk
I is a DAG. No cycles, but you can have multiple roles imply the same role.
Admin implies auditor Admin implies Member Auditor implies reader. Member implies reader
Anything that is member, not reader, is writable my members Anything that is admin, not auditor is writable by admins (only)
On Thu, Dec 13, 2018 at 10:37 AM Sean Pryor pagure@pagure.io wrote:
xaenalt added a new comment to an issue you are following: `` Hmmm, the more I think about it, the more I flip-flop on it I think the readability of "rule:admin or rule:auditor" and "rule:admin or rule:member or rule:auditor" makes reading the rules easier, I know the general direction is to not have users modify them, but the way the access goes, the ones that are read-only calls would just need the additional or rule:auditor, I don't see a way to collapse those down any further. On writer calls, "rule:admin or rule:member" or just "rule:admin" seems the simplest. As for why we should be verbose about admin, it helps to show the difference in which calls are intended for admin-only vs regular members Idk, I know we could collapse them down to a single rule that incorporates all of them like a rule:is_admin_or_member, but that seems to needlessly abstract it. Idk `` To reply, visit the link below or just reply to this email https://pagure.io/openstack-access-policy/issue/7
xaenalt added a new comment to an issue you are following: `` Hmmm, the more I think about it, the more I flip-flop on it
Idk, I know we could collapse them down to a single rule that incorporates all of them like a rule:is_admin_or_member, but that seems to needlessly abstract it. Idk ``
To reply, visit the link below or just reply to this email https://pagure.io/openstack-access-policy/issue/7
Right, it is a DAG, I guess the real question I have is, should we create single rules like: rule:admin rule:admin_or_auditor rule:admin_or_member rule:admin_or_member_or_auditor
or something more obfuscated like rule:admin rule:admin_readable rule:member rule:member_readable
Both approaches seem to be functionally the same as what we're doing now though
And if we should go with one of those approaches, I'm not sure what it buys us over the existing approach
No, because if you change the meaning of the rule, you need to go an update each and every policy line. Policy changes should be infrequent and deliberate.
On Fri, Dec 14, 2018 at 9:53 AM Sean Pryor pagure@pagure.io wrote:
xaenalt added a new comment to an issue you are following: And if we should go with one of those approaches, I'm not sure what it buys us over the existing approach To reply, visit the link below or just reply to this email https://pagure.io/openstack-access-policy/issue/7
xaenalt added a new comment to an issue you are following: And if we should go with one of those approaches, I'm not sure what it buys us over the existing approach
Ok, cool
As for those, I did submit one of those nasty multi-line changes to update reader to auditor to better match upstream
Metadata Update from @xaenalt: - Issue status updated to: Closed (was: Open)