[
https://issues.apache.org/jira/browse/SLING-8766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber updated SLING-8766:
------------------------------------
Description:
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.
was:
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 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.
> 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
> Priority: Major
>
> 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)
