[
https://issues.apache.org/jira/browse/JCR-3966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Klimetschek updated JCR-3966:
---------------------------------------
Description:
Most methods in AccessControlUtils - 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.
was:
Most methods in AccessControlUtils - 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.
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.
> 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 - 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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
