You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "Tobias Bocanegra (JIRA)" <ji...@apache.org> on 2014/01/22 06:59:19 UTC
[jira] [Updated] (OAK-1348) ACE merging not behaving correctly if
not using managed principals
[ https://issues.apache.org/jira/browse/OAK-1348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tobias Bocanegra updated OAK-1348:
----------------------------------
Description:
{{org.apache.jackrabbit.api.security.JackrabbitAccessControlList#addEntry()}} does not work correctly, if the given principal is not retrieved from the PrincipalManager.
Exception:
{noformat}
Caused by: org.apache.jackrabbit.oak.api.CommitFailedException: OakAccessControl0013: Duplicate ACE found in policy
at org.apache.jackrabbit.oak.security.authorization.accesscontrol.AccessControlValidator.accessViolation(AccessControlValidator.java:278)
at org.apache.jackrabbit.oak.security.authorization.accesscontrol.AccessControlValidator.checkValidPolicy(AccessControlValidator.java:188)
{noformat}
this used to work in jackrabbit 2.x.
the problem is probably in {{org.apache.jackrabbit.oak.security.authorization.accesscontrol.ACL#internalAddEntry}} where the principals are "equalled" instead of comparing their names.
note, that adding an ACE with such a principal works, just the merging/overwriting detection doesn't.
test:
{code}
Principal p1 = new Principal() { getName(){return "foo"}};
Principal p2 = new Principal() { getName(){return "foo"}};
acl.addEntry(p1, privileges, true);
acl.addEntry(p2, privileges, false);
...
save(); // throws
{code}
was:
{{org.apache.jackrabbit.api.security.JackrabbitAccessControlList#addEntry()}} does not work correctly, if the given principal is not retrieved from the PrincipalManager.
this used to work in jackrabbit 2.x.
the problem is probably in {{org.apache.jackrabbit.oak.security.authorization.accesscontrol.ACL#internalAddEntry}} where the principals are "equalled" instead of comparing their names.
note, that adding an ACE with such a principal works, just the merging/overwriting detection doesn't.
test:
{code}
Principal p1 = new Principal() { getName(){return "foo"}};
Principal p2 = new Principal() { getName(){return "foo"}};
acl.addEntry(p1, privileges, true);
acl.addEntry(p2, privileges, false);
...
save(); // throws
{code}
> ACE merging not behaving correctly if not using managed principals
> ------------------------------------------------------------------
>
> Key: OAK-1348
> URL: https://issues.apache.org/jira/browse/OAK-1348
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: security
> Affects Versions: 0.15
> Reporter: Tobias Bocanegra
>
> {{org.apache.jackrabbit.api.security.JackrabbitAccessControlList#addEntry()}} does not work correctly, if the given principal is not retrieved from the PrincipalManager.
> Exception:
> {noformat}
> Caused by: org.apache.jackrabbit.oak.api.CommitFailedException: OakAccessControl0013: Duplicate ACE found in policy
> at org.apache.jackrabbit.oak.security.authorization.accesscontrol.AccessControlValidator.accessViolation(AccessControlValidator.java:278)
> at org.apache.jackrabbit.oak.security.authorization.accesscontrol.AccessControlValidator.checkValidPolicy(AccessControlValidator.java:188)
> {noformat}
> this used to work in jackrabbit 2.x.
> the problem is probably in {{org.apache.jackrabbit.oak.security.authorization.accesscontrol.ACL#internalAddEntry}} where the principals are "equalled" instead of comparing their names.
> note, that adding an ACE with such a principal works, just the merging/overwriting detection doesn't.
> test:
> {code}
> Principal p1 = new Principal() { getName(){return "foo"}};
> Principal p2 = new Principal() { getName(){return "foo"}};
> acl.addEntry(p1, privileges, true);
> acl.addEntry(p2, privileges, false);
> ...
> save(); // throws
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)