[
https://issues.apache.org/jira/browse/SLING-8604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16897117#comment-16897117
]
angela commented on SLING-8604:
-------------------------------
while working on a potential fix, i additionally noticed that the same method
is prone to NPE: {{AccessControlUtils.getAccessControlList(session, path)}} may
return null.
> AclUtil.setAcl: invalid assumptions regarding principal lookup
> --------------------------------------------------------------
>
> Key: SLING-8604
> URL: https://issues.apache.org/jira/browse/SLING-8604
> Project: Sling
> Issue Type: Bug
> Components: Repoinit
> Reporter: angela
> Priority: Major
>
> IMHO, {{AclUtil.setAcl}} makes the following invalid assumptions about
> principals:
> # every principal is backed by a user/group defined by jackrabbit user
> management (which already is not necessarily true for the everyone group,
> which was probably the reason for the extra if for everyone)
> # for those cases where a given principal is in fact associated with an known
> user/group, the implementation assumes that the principal name is identical
> to the ID
> for the former it is sufficient to look at the everyone principal or at the
> synchronization mechanism in _oak-auth-external_, which defines an additional
> {{PrincipalProvider}} that does not require principals to be reflected as
> users/goups and for which setting up access control content is equally valid
> (see also _oak-exercise_ module for a simplistic, custom principal provider
> to play around with).
> the latter can easily be illustrated by creating a user/group account with a
> different principal name by calling {{UserManager.createUser(String, String,
> Principal, String)}} or {{UserManager.createGroup(String, Principal, String}}.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
