[
https://issues.apache.org/jira/browse/SLING-10299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17345925#comment-17345925
]
Angela Schreiber commented on SLING-10299:
------------------------------------------
thanks [~enorman] for investigating. i can confirm that the principal-impl
class has not changed substancially since the early days of oak the only
breaking change we had to make in the spi-principal package was due to the
replacement of {{java.security.acl.Group}}, which was deprecated and later
removed in java. as far as updating _org.apache.sling.testing.sling-mock-oak_
is concerned: i don't have a strong preference as long as it works for the
sling team.... this can be picked up once it's needed.
> Allow for removal of access control policies (not just individual entries)
> --------------------------------------------------------------------------
>
> Key: SLING-10299
> URL: https://issues.apache.org/jira/browse/SLING-10299
> Project: Sling
> Issue Type: New Feature
> Components: Repoinit
> Affects Versions: Repoinit JCR 1.1.32, Repoinit Parser 1.6.6
> Reporter: Angela Schreiber
> Assignee: Angela Schreiber
> Priority: Major
> Fix For: Repoinit JCR 1.1.36, Repoinit Parser 1.6.10
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> hi [~bdelacretaz], as outline in SLING-10134 the ability to cleanup access
> control content with repo-init is currently limited. while investigating ways
> to remove resource-based service user permissions in existing installations i
> noticed that there is one piece from the Jackrabbit API missing altogether:
> {{AccessControlManager.removePolicy(String absPath, AccessControlPolicy}}.
> repo-init language today allows for removal of individual access control
> entries and all entries, it doesn't provide the means to drop a policy
> (without specifying which entries to drop).
> the langage extension could look as follows for the 3 main types to set
> access control:
> {code}
> remove ACL on /libs,/apps
> remove ACL for alice, bob, fred
> remove principal ACL for alice, bob
> {code}
> IMO no {{end}} statement would be required as there are no additional entry
> specific statements present.
> since this would also be needed to cleanup AC content for principals that are
> being removed, I would strongly suggest to leave the principal-validation
> step to the repository and not mandate the target principal to exist. In
> order to not break subsequent executions I would also suggest to only log an
> INFO if the policy to remove doesn't exist.
> implementation wise it could look as follows (untested pseudo-code):
> {code}
> JackrabbitAccessControlList acl =
> AccessControlUtils.getAccessControlList(acMgr, jcrPath);
> if (acl != null) {
> acMgr.removePolicy(acl.getPath(), acl)
> } else {
> log.info(".....");
> }
> {code}
> {code}
> PrincipalAccessControlList acl = getPrincipalAccessControlList(acMgr,
> principal)
> if (acl != null) {
> acMgr.removePolicy(acl.getPath(), acl)
> } else {
> log.info(".....");
> }
> {code}
> for the case {{remove ACL for alice, bob, fred}} multiple options exist.... i
> would need to dig into the repo-init code to see what was best. in theory
> {{JackrabbitAccessControlManager.getPolicies(principal)}} should work and one
> only need to make sure not to delete the {{PrincipalAccessControlList}} if
> that existed as well.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
