[
https://issues.apache.org/jira/browse/JCR-3966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15241260#comment-15241260
]
angela commented on JCR-3966:
-----------------------------
Unfortunately you are mistaken... JCR API contract requires the {{Principal}}
to be known and existing and accessible on the repository in order to setup the
{{AccessControlEntry}}:
{quote}
AccessControlException if the specified principal or any of the privileges does
not exist or if some other access control related exception occurs.
{quote}
Within Oak we introduced a configuration option that allows to somewhat relax
that API contract but this is not the default behavior.
In other words: In the default setup, where the only source of {{Principal}}s
is the user management implementation the accessibility of the principal
effectively depends on the accessibility of the user/group. Please note
however, that having Principal Management built on top of User Management is
just one possible implementation and there are various plans to provide
additional implementations of the principal management.
Please refer to the Oak documentation that provides a lot of details regarding
the difference between user management and principal management. Also the
oak-exercise module ships with an additional {{PrincipalConfiguration}} OSGi
component that can be plugged into a running OSGi-based Oak-setup to illustrate
how additional sources for {{Principal}}s can be leveraged independent of the
user management API.
> 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)
