[
https://issues.apache.org/jira/browse/JCR-3966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela closed JCR-3966.
-----------------------
> AccessControlUtils should not depend on ability to read other users
> -------------------------------------------------------------------
>
> Key: JCR-3966
> URL: https://issues.apache.org/jira/browse/JCR-3966
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-jcr-commons
> Affects Versions: 2.12.1
> Reporter: Alexander Klimetschek
>
> Most methods in
> [AccessControlUtils|https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/commons/jackrabbit/authorization/AccessControlUtils.java]
> - while taking the principal name as argument - always [fetch the
> principal|https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/commons/jackrabbit/authorization/AccessControlUtils.java#L369]
> via the jackrabbit PrincipalManager.
> This (at least in Oak) requires the user to have read access on the user
> behind the principal, otherwise it returns null and an NPE is thrown and no
> ACs are set.
> Setting an AC however does not (and should not) require access to the
> complete user, and can be done by implementing the principal on the spot:
> {code}
> new JackrabbitPrincipal() {
> @Override
> public String getName() {
> return principalName;
> }
> };
> {code}
> This uses the JackrabbitPrincipal as the [PrincipalImpl in Oak
> casts|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/principal/PrincipalImpl.java#L51]
> to this one for the equality test.
> Filevault does the
> [same|https://github.com/apache/jackrabbit-filevault/blob/64caa29325452c1adf968ae05e2308b37f3600cc/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/JackrabbitACLImporter.java#L246].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
