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/11/19 09:46:00 UTC

[jira] [Closed] (SLING-8766) AclVisitor.setPrincipalAcl: be more lenient with unsupported principals

     [ https://issues.apache.org/jira/browse/SLING-8766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Robert Munteanu closed SLING-8766.
----------------------------------

> AclVisitor.setPrincipalAcl: be more lenient with unsupported principals 
> ------------------------------------------------------------------------
>
>                 Key: SLING-8766
>                 URL: https://issues.apache.org/jira/browse/SLING-8766
>             Project: Sling
>          Issue Type: Improvement
>          Components: Repoinit
>            Reporter: Angela Schreiber
>            Assignee: Robert Munteanu
>            Priority: Major
>             Fix For: Repoinit JCR 1.1.16
>
>          Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> i noticed the following potential for improvement with {{AclVisitor.setPrincipalAcl}} when testing it in an AEM upgrade scenario. due to the fact that repo-init doesn't verify the _intermedidatePath_ when a user/group to be created already exists but happens to be located at the different subtree, {{AclVisitor.setPrincipalAcl}} may fail upon upgrade _if_ the existing principal turns out to be not supported. this happens irrespective of the fact that the repo init statements were perfectly fine if run initially.
> example with filter configured with supported path _/home/users/system/principalbased_
> {code}
> create service user foo with path system/principalbased
> set principal ACL for foo
>     allow jcr:read,rep:write on /content
> end
> {code}
> if 'foo' already existed at _/home/users/system/elsewhere_ the repo init code does not make an attempt to move 'foo' to the new location and is fine with 'foo' existing. however, the ac-setup will fail.
> i would suggest to improve this by log.INFO that no {{PrincipalAccessControlList}} can be found instead of throwing {{IllegalStateException}}. In the subsequent access control setup verify if an equivalent effective {{AccessControlEntry}} is present and only throw the exception if no such entry exists, meaning that the effective access control setup resulting from repo-init is incomplete.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)