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