[
https://issues.apache.org/jira/browse/SLING-10299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17339652#comment-17339652
]
Angela Schreiber edited comment on SLING-10299 at 5/5/21, 1:23 PM:
-------------------------------------------------------------------
[~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. and i can't think of
any reason why a privilege should be name access-control-list. a privilege is
associated with some sort of action.
was (Author: anchela):
[~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)
