jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Konrad Windszus (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (OAK-7952) JCR System users do no longer consider group ACEs of groups they are member of
Date Mon, 10 Dec 2018 13:15:00 GMT

     [ https://issues.apache.org/jira/browse/OAK-7952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Konrad Windszus updated OAK-7952:
---------------------------------
    Description: 
In Oak 1.8.3 the JCR system users (JCR-3802) do no longer consider the access control entries
bound to a group principal (belonging to a group they are member of). Only direct ACEs seem
to be considered.
I used the attached simple servlet to test read access of an existing service-user "workflow-service".
Unfortunately it throws a {{javax.jcr.PathNotFoundException}} although the service user should
inherit  read access to the accessed path via its group membership. It works flawlessly in
case the system user has direct read access to that path.

Some more information about {{SlingRepository.createServiceSession(...)}}. Internally the
service user implementation does a lookup of the actual service user name and then does impersonation
from a new admin session (https://github.com/apache/sling-org-apache-sling-jcr-base/blob/de884b669836aacb2666da1e7bae1a6735de3bdb/src/main/java/org/apache/sling/jcr/base/AbstractSlingRepository2.java#L197)

  was:
In Oak 1.8.3 the JCR system users (JCR-3802) do no longer consider the access control entries
bound to a group principal (belonging to a group they are member of). Only direct ACEs seem
to be considered.
I used the attached simple servlet to test read access of an existing service-user "workflow-service".
Unfortunately it throws a {{javax.jcr.PathNotFoundException}} although the service user should
inherit  read access to the accessed path via its group membership. It works flawlessly in
case the system user has direct read access to that path.

Some more information from {{SlingRepository}}. Internally the service user implementation
does a lookup of the actual service user name and then does impersonation from a new admin
session (https://github.com/apache/sling-org-apache-sling-jcr-base/blob/de884b669836aacb2666da1e7bae1a6735de3bdb/src/main/java/org/apache/sling/jcr/base/AbstractSlingRepository2.java#L197)


> JCR System users do no longer consider group ACEs of groups they are member of
> ------------------------------------------------------------------------------
>
>                 Key: OAK-7952
>                 URL: https://issues.apache.org/jira/browse/OAK-7952
>             Project: Jackrabbit Oak
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.8.3
>            Reporter: Konrad Windszus
>            Priority: Major
>         Attachments: OAK-7952_test-servlet.java
>
>
> In Oak 1.8.3 the JCR system users (JCR-3802) do no longer consider the access control
entries bound to a group principal (belonging to a group they are member of). Only direct
ACEs seem to be considered.
> I used the attached simple servlet to test read access of an existing service-user "workflow-service".
Unfortunately it throws a {{javax.jcr.PathNotFoundException}} although the service user should
inherit  read access to the accessed path via its group membership. It works flawlessly in
case the system user has direct read access to that path.
> Some more information about {{SlingRepository.createServiceSession(...)}}. Internally
the service user implementation does a lookup of the actual service user name and then does
impersonation from a new admin session (https://github.com/apache/sling-org-apache-sling-jcr-base/blob/de884b669836aacb2666da1e7bae1a6735de3bdb/src/main/java/org/apache/sling/jcr/base/AbstractSlingRepository2.java#L197)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message