[
https://issues.apache.org/jira/browse/SLING-10156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber resolved SLING-10156.
--------------------------------------
Resolution: Duplicate
this has been addressed by SLING-12115. thanks [~jsedding] :)
> 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.20.10#820010)
