[
https://issues.apache.org/jira/browse/SLING-10299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17342811#comment-17342811
]
Eric Norman edited comment on SLING-10299 at 5/11/21, 7:15 PM:
---------------------------------------------------------------
[~angela] Do you think the oak.version in the pom.xml is too old here? It
seems to cause troubles with the feature analyzer when including the latest
org.apache.sling.jcr.repoinit bundle. It looks to me the major version of the
org.apache.jackrabbit.oak.spi.security.principal package was changed to 2.x in
the 1.26.0 version so the import package version constraint doesn't match with
the more recent versions of the oak bundles.
Specifically, I saw the following error in my maven build output (from the
feature analyzer) which failed the build:
{color:#de350b}{{[ERROR]
org.apache.sling:org.apache.sling.jcr.repoinit:1.1.35-SNAPSHOT: is importing
package(s) Package
org.apache.jackrabbit.oak.spi.security.principal;version=[1.7,2) in start level
20 but no bundle is exporting these for that start level in the required
version range.}}{color}
The oak-security-spi version 1.38.0 that I am using exports that package as
org.apache.jackrabbit.oak.spi.security.principal,version=2.1.0
was (Author: enorman):
[~angela] Do you think the oak.version in the pom.xml is too old here? It
seems to cause troubles with the feature analyzer when including the latest
org.apache.sling.jcr.repoinit bundle. It looks to me the major version of the
org.apache.jackrabbit.oak.spi.security.principal package was changed to 2.x in
the 1.26.0 version so the import package version constraint doesn't match with
the more recent versions of the oak bundles.
Specifically, I saw the following error in my maven build output (from the
feature analyzer) which failed the build:
{color:#de350b}{{[ERROR]
org.apache.sling:org.apache.sling.jcr.repoinit:1.1.35-SNAPSHOT: is importing
package(s) Package
org.apache.jackrabbit.oak.spi.security.principal;version=[1.7,2) in start level
20 but no bundle is exporting these for that start level in the required
version range.}}{color}
The oak-security-spi version 1.38.0 that I am using exports that package as
org.apache.jackrabbit.oak.spi.security.principal,version=2.1.0
> 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)
