Angela Schreiber created SLING-10156:
----------------------------------------
Summary: 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
[~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)
