You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Bertrand Delacretaz (Jira)" <ji...@apache.org> on 2021/06/21 08:56:00 UTC

[jira] [Closed] (SLING-10299) Allow for removal of access control policies (not just individual entries)

     [ https://issues.apache.org/jira/browse/SLING-10299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bertrand Delacretaz closed SLING-10299.
---------------------------------------

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