[SLING-10156] Create access control entries for unknown principals

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Duplicate
• Component/s: Repoinit
• Assignee: Unassigned
• Reporter: Angela Schreiber
• Created: 23/Feb/21 08:25
• Updated: 19/Mar/24 16:07
• Resolved: 19/Mar/24 16:07

Description

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

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

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

Issue Links

• is fixed by: SLING-12115 Repoinit should leave enforcement of importBehaviour for ACL creation to JCR
• relates to: SLING-10134 Deleting ACEs for users that don't exist is impossible