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

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

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

Andrei Shilov (Jira)

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