[ https://issues.apache.org/jira/browse/SLING-10299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17339652#comment-17339652 ]
Angela Schreiber commented on SLING-10299: ------------------------------------------ [~bdelacretaz], not sure i can follow the reasoning.... ACL-privilege? sorry you lost me with that one :)..... the remove-entries call are afaik always placed inside a 'set ACL' statement as follows: {code} set (principal) ACL on/for ... remove privilegeNames or * on/for ... end {code} this contrasts what i propose here which is not inside a 'set (principal) ACL' statement but a separate {{remove (principal) ACL}} top-level statement (without an end). the reason why i picked 'remove' was the fact that the corresponding JCR/Jackrabbit API calls are name {{removePolicy}} and not 'deletePolicy'. but if there is no need keep it consistent with the well-known JCR method naming, i don't have a strong preference. i can also live with {{delete ACL on/for ...}} and {{delete principal ACL for....}}. but the test you mention look really confusing.... jcr:ACL? ACL-privilege? ACL stands for access control list, which is one possible type of access control policy. > 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 > > 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)