You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-dev@jackrabbit.apache.org by Angela Schreiber <an...@adobe.com.INVALID> on 2019/01/21 12:25:03 UTC
Re: Request for info on Oak restriction management for JCR-SQL2
queries
Hi Søren
I would expect the query results to reflect the effective permissions i.e. the result set should only return what is accessible to the editing session and the results should be consistent with calls to Session.getNode/getProperty/getItem.
Without having a closer look at the code base or your test the described behavior looks look a bug to me... but I have to add that I am not too familiar with the Oak query engine and how it evaluates permissions. May I ask you to create a JIRA ticket at https://issues.apache.org/jira/projects/OAK/issues with the description below and the test-code?
If it wasn't a bug but a conscious decision / known limitation of the query, I would at least want to update the security documentation to make sure we mention (and have an explanation for) the behavior, that looks inconsistent.
Kind regards
Angela
________________________________
From: Søren Jensen <so...@systematic.com>
Sent: Monday, January 21, 2019 8:54 AM
To: users@jackrabbit.apache.org
Subject: Request for info on Oak restriction management for JCR-SQL2 queries
Hi
This is a shortened version of https://stackoverflow.com/questions/54280740/adding-restrictions-to-acls-yields-empty-results-for-queries-in-jackrabbit-oak
I'm looking for information on Jackrabbit Oak's restriction management w.r.t. security. This primarily stems from a specific case below where I receive some unexpected results, as I did not expect a query to filter away the results it did.
Using the following repository structure below:
/
node [nt:unstructured]
subnode [nt:unstructured]
On 'node', I add an access control entry with privilege 'JCR_ALL' for 'user' (with principal 'user') together with a restriction for rep:glob -> "", such that user do not have access to the children - in this case, only 'subnode'.
It works as expected when using session.getNode for 'user':
- session.getNode("/node") returns the node
- session.getNode("/node/subnode") throws PathNotFoundException as expected due to the restriction.
However, when I execute the following JCR-SQL2 query as 'user':
SELECT * FROM [nt:unstructured]
I get no results back. Here I would have expected to get /node, as it is otherwise available when using session.getNode. Removing the restriction yields the expected result of both /node and /node/subnode.
I'm using Oak version 1.10.0.
If anybody is able to provide some insight into why this is not the case, it would be greatly appreciated. With that said, I really appreciate the thorough documentation on your website.
Thanks in advance,
Søren
Re: Request for info on Oak restriction management for JCR-SQL2
queries
Posted by Angela Schreiber <an...@adobe.com.INVALID>.
Hi Søren
Thanks. I will look into it and follow up on the jira issue.
Kind regards
Angela
________________________________
From: Søren Jensen <so...@systematic.com>
Sent: Monday, January 21, 2019 2:59 PM
To: users@jackrabbit.apache.org; oak-dev@jackrabbit.apache.org
Subject: RE: Request for info on Oak restriction management for JCR-SQL2 queries
Hi Angela
Thank you for the response. I've created an issue at https://issues.apache.org/jira/browse/OAK-7997 with the test code included.
-----Original Message-----
From: Angela Schreiber <an...@adobe.com.INVALID>
Sent: 21. januar 2019 13:25
To: users@jackrabbit.apache.org; oak-dev@jackrabbit.apache.org
Subject: Re: Request for info on Oak restriction management for JCR-SQL2 queries
Hi Søren
I would expect the query results to reflect the effective permissions i.e. the result set should only return what is accessible to the editing session and the results should be consistent with calls to Session.getNode/getProperty/getItem.
Without having a closer look at the code base or your test the described behavior looks look a bug to me... but I have to add that I am not too familiar with the Oak query engine and how it evaluates permissions. May I ask you to create a JIRA ticket at https://issues.apache.org/jira/projects/OAK/issues with the description below and the test-code?
If it wasn't a bug but a conscious decision / known limitation of the query, I would at least want to update the security documentation to make sure we mention (and have an explanation for) the behavior, that looks inconsistent.
Kind regards
Angela
________________________________
From: Søren Jensen <so...@systematic.com>
Sent: Monday, January 21, 2019 8:54 AM
To: users@jackrabbit.apache.org
Subject: Request for info on Oak restriction management for JCR-SQL2 queries
Hi
This is a shortened version of https://stackoverflow.com/questions/54280740/adding-restrictions-to-acls-yields-empty-results-for-queries-in-jackrabbit-oak
I'm looking for information on Jackrabbit Oak's restriction management w.r.t. security. This primarily stems from a specific case below where I receive some unexpected results, as I did not expect a query to filter away the results it did.
Using the following repository structure below:
/
node [nt:unstructured]
subnode [nt:unstructured]
On 'node', I add an access control entry with privilege 'JCR_ALL' for 'user' (with principal 'user') together with a restriction for rep:glob -> "", such that user do not have access to the children - in this case, only 'subnode'.
It works as expected when using session.getNode for 'user':
- session.getNode("/node") returns the node
- session.getNode("/node/subnode") throws PathNotFoundException as expected due to the restriction.
However, when I execute the following JCR-SQL2 query as 'user':
SELECT * FROM [nt:unstructured]
I get no results back. Here I would have expected to get /node, as it is otherwise available when using session.getNode. Removing the restriction yields the expected result of both /node and /node/subnode.
I'm using Oak version 1.10.0.
If anybody is able to provide some insight into why this is not the case, it would be greatly appreciated. With that said, I really appreciate the thorough documentation on your website.
Thanks in advance,
Søren
Re: Request for info on Oak restriction management for JCR-SQL2
queries
Posted by Angela Schreiber <an...@adobe.com.INVALID>.
Hi Søren
Thanks. I will look into it and follow up on the jira issue.
Kind regards
Angela
________________________________
From: Søren Jensen <so...@systematic.com>
Sent: Monday, January 21, 2019 2:59 PM
To: users@jackrabbit.apache.org; oak-dev@jackrabbit.apache.org
Subject: RE: Request for info on Oak restriction management for JCR-SQL2 queries
Hi Angela
Thank you for the response. I've created an issue at https://issues.apache.org/jira/browse/OAK-7997 with the test code included.
-----Original Message-----
From: Angela Schreiber <an...@adobe.com.INVALID>
Sent: 21. januar 2019 13:25
To: users@jackrabbit.apache.org; oak-dev@jackrabbit.apache.org
Subject: Re: Request for info on Oak restriction management for JCR-SQL2 queries
Hi Søren
I would expect the query results to reflect the effective permissions i.e. the result set should only return what is accessible to the editing session and the results should be consistent with calls to Session.getNode/getProperty/getItem.
Without having a closer look at the code base or your test the described behavior looks look a bug to me... but I have to add that I am not too familiar with the Oak query engine and how it evaluates permissions. May I ask you to create a JIRA ticket at https://issues.apache.org/jira/projects/OAK/issues with the description below and the test-code?
If it wasn't a bug but a conscious decision / known limitation of the query, I would at least want to update the security documentation to make sure we mention (and have an explanation for) the behavior, that looks inconsistent.
Kind regards
Angela
________________________________
From: Søren Jensen <so...@systematic.com>
Sent: Monday, January 21, 2019 8:54 AM
To: users@jackrabbit.apache.org
Subject: Request for info on Oak restriction management for JCR-SQL2 queries
Hi
This is a shortened version of https://stackoverflow.com/questions/54280740/adding-restrictions-to-acls-yields-empty-results-for-queries-in-jackrabbit-oak
I'm looking for information on Jackrabbit Oak's restriction management w.r.t. security. This primarily stems from a specific case below where I receive some unexpected results, as I did not expect a query to filter away the results it did.
Using the following repository structure below:
/
node [nt:unstructured]
subnode [nt:unstructured]
On 'node', I add an access control entry with privilege 'JCR_ALL' for 'user' (with principal 'user') together with a restriction for rep:glob -> "", such that user do not have access to the children - in this case, only 'subnode'.
It works as expected when using session.getNode for 'user':
- session.getNode("/node") returns the node
- session.getNode("/node/subnode") throws PathNotFoundException as expected due to the restriction.
However, when I execute the following JCR-SQL2 query as 'user':
SELECT * FROM [nt:unstructured]
I get no results back. Here I would have expected to get /node, as it is otherwise available when using session.getNode. Removing the restriction yields the expected result of both /node and /node/subnode.
I'm using Oak version 1.10.0.
If anybody is able to provide some insight into why this is not the case, it would be greatly appreciated. With that said, I really appreciate the thorough documentation on your website.
Thanks in advance,
Søren
RE: Request for info on Oak restriction management for JCR-SQL2
queries
Posted by Søren Jensen <so...@systematic.com>.
Hi Angela
Thank you for the response. I've created an issue at https://issues.apache.org/jira/browse/OAK-7997 with the test code included.
-----Original Message-----
From: Angela Schreiber <an...@adobe.com.INVALID>
Sent: 21. januar 2019 13:25
To: users@jackrabbit.apache.org; oak-dev@jackrabbit.apache.org
Subject: Re: Request for info on Oak restriction management for JCR-SQL2 queries
Hi Søren
I would expect the query results to reflect the effective permissions i.e. the result set should only return what is accessible to the editing session and the results should be consistent with calls to Session.getNode/getProperty/getItem.
Without having a closer look at the code base or your test the described behavior looks look a bug to me... but I have to add that I am not too familiar with the Oak query engine and how it evaluates permissions. May I ask you to create a JIRA ticket at https://issues.apache.org/jira/projects/OAK/issues with the description below and the test-code?
If it wasn't a bug but a conscious decision / known limitation of the query, I would at least want to update the security documentation to make sure we mention (and have an explanation for) the behavior, that looks inconsistent.
Kind regards
Angela
________________________________
From: Søren Jensen <so...@systematic.com>
Sent: Monday, January 21, 2019 8:54 AM
To: users@jackrabbit.apache.org
Subject: Request for info on Oak restriction management for JCR-SQL2 queries
Hi
This is a shortened version of https://stackoverflow.com/questions/54280740/adding-restrictions-to-acls-yields-empty-results-for-queries-in-jackrabbit-oak
I'm looking for information on Jackrabbit Oak's restriction management w.r.t. security. This primarily stems from a specific case below where I receive some unexpected results, as I did not expect a query to filter away the results it did.
Using the following repository structure below:
/
node [nt:unstructured]
subnode [nt:unstructured]
On 'node', I add an access control entry with privilege 'JCR_ALL' for 'user' (with principal 'user') together with a restriction for rep:glob -> "", such that user do not have access to the children - in this case, only 'subnode'.
It works as expected when using session.getNode for 'user':
- session.getNode("/node") returns the node
- session.getNode("/node/subnode") throws PathNotFoundException as expected due to the restriction.
However, when I execute the following JCR-SQL2 query as 'user':
SELECT * FROM [nt:unstructured]
I get no results back. Here I would have expected to get /node, as it is otherwise available when using session.getNode. Removing the restriction yields the expected result of both /node and /node/subnode.
I'm using Oak version 1.10.0.
If anybody is able to provide some insight into why this is not the case, it would be greatly appreciated. With that said, I really appreciate the thorough documentation on your website.
Thanks in advance,
Søren