You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "angela (JIRA)" <ji...@apache.org> on 2019/07/31 12:24:00 UTC

[jira] [Commented] (SLING-8604) AclUtil.setAcl: invalid assumptions regarding principal lookup

    [ 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)