[
https://issues.apache.org/jira/browse/SLING-8604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu resolved SLING-8604.
------------------------------------
Resolution: Fixed
Thank you for the patch [~angela], I have applied it in
[sling-org-apache-sling-jcr-repoinit commit
bdad3db|https://github.com/apache/sling-org-apache-sling-jcr-repoinit/commit/bdad3db].
> 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
> Assignee: Robert Munteanu
> Priority: Major
> Fix For: Repoinit JCR 1.1.14
>
> Attachments: SLING-8604.patch
>
>
> 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
(v8.3.2#803003)
