[
https://issues.apache.org/jira/browse/JCR-3966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15241638#comment-15241638
]
Alexander Klimetschek commented on JCR-3966:
--------------------------------------------
{quote}JCR API contract requires the Principal to be known and existing and
accessible on the repository{quote}
But this is not enforced in the implementation (otherwise filevault would not
work, and probably other use cases). Please note that this is about the
AccessControlUtils in jackrabbit-jcr-commons, which does this check by itself,
outside the JCR/Jackrabbit API.
Here is our use case: we have a collaboration application, where users can
share folders which each other, meaning they need to grant ACs for other
users/principals on the folders they own.
As per the security team recommendation, we are using public user profiles
(i.e. subfolders inside the user homes that are open to the other users), so
that the actual user home = user is not readable by other users. When this was
discussed, it was pointed out by the security folks that setting ACs for
another principal does not require read access to the user behind it.
What you say presents a conflict now. Quo vadis?
It works with a custom copy of these helper methods we have in our code, but it
would be great to not duplicate common utility code.
> 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)
