-
Notifications
You must be signed in to change notification settings - Fork 92
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
Combinations of allow/deny rules with actions and repGlob are not fully set #48
Comments
The reason for that is that the Security API for setting actions does not support restrictions. Therefore what we do now in the implementation is
In your example the first action and the last action without restrictions are redundant. |
But if I change the order then the rights are not the same. |
Yes, changing the order will change the semantics here. But as a workaround you can split the deny and allow parts into different groups, where one is member of the other. That way the actions are not removed before setting the restrictions. |
A similar bug is happening with just these two rules:
Read privilege will not be included in deny rule. |
Another workaround is to use privileges instead of actions. |
Workaround verified. Actions done:
Before:
After:
|
Added comment to README that privileges should be used. |
I would prefer to keep this issue open and reference this issue in the readme (to provide a littlebit more information around that limitation) |
Another possible workaround is to use repGlob: "*":
|
With the changes from #155, the following example works perfectly fine (and produces three ACEs):
|
Example:
permission: deny
actions: read,acl_read
privileges:
repGlob:
permission: allow
actions: read,acl_read
privileges:
repGlob: ""
permission: allow
actions: read,acl_read
privileges:
repGlob: /jcr:*
I just get the two allow rules. The deny rule is not set.
Probably, this is because when setting the first allow rule without repglob then the deny rule is removed. I saw this kind of effect when I debugged the tool some time ago, OAK seems to remove rules if they are obsoleted by another rule.
Probably, here the second rule with allow removes the first rule since it is added without repglob first (added in a second code step).
The text was updated successfully, but these errors were encountered: