[
https://issues.apache.org/jira/browse/SLING-10156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17289936#comment-17289936
]
Bertrand Delacretaz commented on SLING-10156:
---------------------------------------------
Thanks for this [~angela].
Would you be able to supply failing tests that precisely expose the problem?
Along the lines of the existing
[PrincipalBasedAclTest|https://github.com/apache/sling-org-apache-sling-jcr-repoinit/blob/master/src/test/java/org/apache/sling/jcr/repoinit/PrincipalBasedAclTest.java],
or maybe as a new test class in that package as that one is quite big already.
I think that's best starting point for fixing this.
> Create access control entries for unknown principals
> ----------------------------------------------------
>
> Key: SLING-10156
> URL: https://issues.apache.org/jira/browse/SLING-10156
> Project: Sling
> Issue Type: Bug
> Components: Repoinit
> Reporter: Angela Schreiber
> Priority: Major
>
> [~bdelacretaz], today the JCR repo-init implementation limits creation of
> access control content to principals known to the repository (see also
> SLING-10134 for a related ticket wrt to removing access control entries):
> {code}
> // first try PrincipalManager.getPrincipal(String)
> Principal principal = AccessControlUtils.getPrincipal(session, name);
> if (principal == null) {
> // backwards compatibility: fallback to original code
> treating principal name as authorizable ID (see SLING-8604)
> final Authorizable authorizable =
> UserUtil.getAuthorizable(session, name);
> checkState(authorizable != null, "Authorizable not found:" +
> name);
> principal = authorizable.getPrincipal();
> }
> checkState(principal != null, "Principal not found: " + name); //
> <- here it fails if principal does not exist
> {code}
> While JCR access control API mandates that a principal must be known to the
> repository, it is possible both with Apache Jackrabbit 2.x and in Apache
> Jackrabbit Oak to relax that contract (see ImportBehavior.BESTEFFORT [0]).
> The main reason for this is the fact that principals may only be installed at
> a later stage and packaging them together with (resource-based) access
> control isn't always feasible/desirable (see for example Jackrabbit vault
> [1]).
> In other words: repo-init should delegate the principal validation step (and
> whether or not the strict JCR contract is enforced) to the repository itself.
> In Sling RepoInit this is relevant under the following circumstances:
> - cleaning up access control content when the principal no longer exists (see
> SLING-10134)
> - setting up access control content in the initial repository initialization,
> while principals are not yet available (maybe installed later with content
> packages). this becomes increasingly relevant with a composite NodeStore
> setup, where certain trees of the repository are marked as immutable and thus
> might be initialized independently of the mutable stores (that e.g. would
> include the group nodes).
> NOTE: delegating the principal validation step to the repository, may also
> require the principal-equality test in
> https://github.com/apache/sling-org-apache-sling-jcr-repoinit/blob/master/src/main/java/org/apache/sling/jcr/repoinit/impl/AclUtil.java#L399
> to be adjusted (e.g. reducing to comparing names as it is done in [2])
> [~karlpauls], [~cziegeler], fyi
> [0]
> http://jackrabbit.apache.org/oak/docs/security/accesscontrol/default.html#xml_import
> [1]
> https://github.com/apache/jackrabbit-filevault/blob/f785fcb24d4cbd01c734e9273310a925c29ae15b/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/JackrabbitACLImporter.java
> [2]
> https://github.com/apache/jackrabbit-filevault/blob/f785fcb24d4cbd01c734e9273310a925c29ae15b/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/JackrabbitACLImporter.java#L290
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
