jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Mueller (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (OAK-1083) Query with descendent node and access control fails to return result
Date Wed, 09 Oct 2013 08:18:41 GMT

    [ https://issues.apache.org/jira/browse/OAK-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790154#comment-13790154
] 

Thomas Mueller edited comment on OAK-1083 at 10/9/13 8:17 AM:
--------------------------------------------------------------

> It might be better if we move the access check a layer above and not mix it as part of
query execution i.e. filter the result after a cursor result satisfies the constraints

Well, that way you could bypass security checks. For example, let's assume you have a content
structure as follows, where a user can only read the nodes /user/a and /user/b, but not /user/.../content.
You could use a join of the form:

{code}
select a.* from a inner join b on (b is child of a) where b.password like 'x%'
{code}

Because the query only potentially reads /user/a and /user/b nodes, it would work. But it
would internally read /user/.../content, which is not allowed. And even thought the query
result doesn't contain the node with the password directly, it would be relatively simple
to figure out what the password is, by running multiple queries (password like 'a%', 'b%',
'c%', 'ca%', 'cb%',...)


was (Author: tmueller):
> It might be better if we move the access check a layer above and not mix it as part of
query execution i.e. filter the result after a cursor result satisfies the constraints

Well, that way you could bypass security checks. For example, let's assume you have a content
structure as follows, where a user can only read the nodes /user/a and /user/b, but not /user/.../content.
You could use a join of the form:

{code}
select a.* from a inner join b on (b is child of a) where b.password like 'x%'
{code}

Because the query only potentially reads /user/a and /user/b nodes, it would work. But it
would internally read /user/.../content, which is not allowed. And even thought the query
doesn't read the password directly, it would be relatively simple to figure out what the password
is, by running multiple queries (password like 'a%', 'b%', 'c%', 'ca%', 'cb%',...)

> Query with descendent node and access control fails to return result
> --------------------------------------------------------------------
>
>                 Key: OAK-1083
>                 URL: https://issues.apache.org/jira/browse/OAK-1083
>             Project: Jackrabbit Oak
>          Issue Type: Bug
>          Components: core, security
>    Affects Versions: 0.9
>            Reporter: Chetan Mehrotra
>            Priority: Minor
>              Labels: compatibility
>         Attachments: OAK-1083-testcase.patch
>
>
> The scenario is bit complex. Running a query with following condition does not give any
result
> *  Node path is like {{/home/users/geometrixx-outdoors/emily.andrews@mailinator.com/social/relationships/following/aaron.mcdonald@mailinator.com}}
> * It has a Glob jcr:read for everyone at {{\*/social/relationships/following/\*}}
> * The query is like 
> bq. /jcr:root/home//social/relationships/following//*[id='aaron.mcdonald@mailinator.com']
> * The query is executed with anonymous session
> On JR2 it returns expected result while on Oak it does not give any result



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Mime
View raw message