Skip to content
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

Order of permissions in ACL matters in overlapping principals #21

Open
mabagoury opened this issue May 12, 2023 · 1 comment
Open

Order of permissions in ACL matters in overlapping principals #21

mabagoury opened this issue May 12, 2023 · 1 comment

Comments

@mabagoury
Copy link

mabagoury commented May 12, 2023

In the add_items endpoint, the ACL to be checked is:

NewItemAcl = [(Deny, "user:bob", "create"), (Allow, Authenticated, "create")]

You can see that user bob has 2 principals (user:bob and Authenticated) mentioned with the required permission: create in the ACL. But the actions collide. One principal allows access. The other denies it.
So, what is the final result when Bob tries to add an item? With the ACL above, he is denied access. But if you just change the order of tuples in the list to be the following:

NewItemAcl = [(Allow, Authenticated, "create"), (Deny, "user:bob", "create")]

He will be granted access!

@mabagoury
Copy link
Author

mabagoury commented May 12, 2023

This happens as the ACL is checked in order for matching permission and principal. In many scenarios, this doesn't matter. But if you need to use the library for a use case with principals with overlapping permissions, order matters. An example is having some users with a role allowed to do something but excluding a specific user holding that role from access. In this case, you need to always add the most specific principals at the beginning of the ACL.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant