[
https://issues.apache.org/jira/browse/SLING-10299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17343525#comment-17343525
]
Eric Norman commented on SLING-10299:
-------------------------------------
[~angela] Ok. I took a quick look at what from the
org.apache.jackrabbit.oak.spi.security.principal package is used in the
(non-test) code and
org.apache.jackrabbit.oak.spi.security.principal.PrincipalImpl appears to be
the only class used anywhere. That class doesn't appear to have any changes
between the 1.16.0 and the latest version so it seems like it should be safe to
relax the import version range with the same solution that was used for
SLING-9316
Or would you prefer that someone update and release a 3.0.0-1.26.0 version of
_org.apache.sling.testing.sling-mock-oak_ and update the dependency and any
tests to compensate?
> 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)
