You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Robert Munteanu (JIRA)" <ji...@apache.org> on 2019/08/06 08:48:00 UTC

[jira] [Comment Edited] (SLING-8607) AclUtil.setAcl ignores return value of JackrabbitAccessControlList.addEntry

    [ https://issues.apache.org/jira/browse/SLING-8607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16900783#comment-16900783 ] 

Robert Munteanu edited comment on SLING-8607 at 8/6/19 8:47 AM:
----------------------------------------------------------------

Thanks for the report [~angela].

These checks were added specifically for {{CompositeNodeStore}} setups where some paths are effectively read-only. So I cannot rely on the return value of a method to check if the access control entry was added, since the invocation would fail. Is there a safer way of knowing if the access control entry is applied?

(_edit_: I did look at the code after all ...)


was (Author: rombert):
Thanks for the report [~angela].

Without looking at the code right now, I can say that the checks were added specifically for {{CompositeNodeStore}} setups where some paths are effectively read-only. So I cannot rely on the return value of a method to check if the access control entry was added, since the invocation would fail. Is there a safer way of knowing if the access control entry is applied?

> AclUtil.setAcl ignores return value of JackrabbitAccessControlList.addEntry
> ---------------------------------------------------------------------------
>
>                 Key: SLING-8607
>                 URL: https://issues.apache.org/jira/browse/SLING-8607
>             Project: Sling
>          Issue Type: Bug
>          Components: Repoinit
>            Reporter: angela
>            Priority: Minor
>
> [~rombert], {{AclUtil.setAcl}} attempts to avoid adding redundant entries (and writing an unmodified policy back to the repository).
> however, it ignores the return value of {{JackrabbitAccessControlList.addEntry}}, which as far as i remember indicates if the given policy has been modified by the given call. i would recommend to take the return value into consideration instead of always setting 'changed = true'.
> in addition: i am not totally convinced that it is wise to 'manually' compare the existing entries with the ones to add and it might well lead to subtle inconsistencies. also, depending on the exact implementation of the {{JackrabbitAccessControlList}}, adding an entry (even if already contained) may effectively alter the policy (e.g. by appending the entry and thus affecting the overall outcome of the evaluation). in other words: IMO it would be better to rely on the capability of the {{JackrabbitAccessControlList}} to determine if an entry was added or not (also the {{expandPrivileges}} may be achieved in an optimized fashion with the acl-implementation).



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)