Copying nodes with access control restrictions

["Lemes, Fernando" <fe...@hp.com>]

   Hi guys,

   I'm dealing with some access control problems trying to migrate a project from Jackrabbit 2.8.x to Oak 1.0.

   I have a user1 sharing a node with user2, but the user2 cannot copy that node (using session.getWorkspace().copy(<originNode>,<destNode>) method).. the Oak code checks if the parent for the origin node is protected, but the user2 doesn't have any permission on that node. Is this the expected behavior?

   Regards,

Fernando Lemes da Silva
Software Engineer - Brazil R&D
fernando.lemes@hp.com<ma...@hp.com>
+55-11-4197-8124

RE: Copying nodes with access control restrictions

["Lemes, Fernando" <fe...@hp.com>]

   Thanks for the reply, Angela!

   I've added a unit test for this scenario on the CopyTest.java file.. it fails exactly on the same point my application is failing. After that I create an issue OAK-2810 and added a patch for that file.

   It seems that I should not check the parent node (from the source) when doing this copy operation, but maybe there was a reason to do that.. I don't know. (I ran the tests and they were ok.. but..)



Fernando Lemes da Silva
Software Designer - Brazil R&D
fernando.lemes@hp.com
+55-11-4197-8124

-----Original Message-----
From: Angela Schreiber [mailto:anchela@adobe.com] 
Sent: sexta-feira, 24 de abril de 2015 12:06
To: oak-dev@jackrabbit.apache.org
Subject: Re: Copying nodes with access control restrictions

hi fernando

i didn't try it out myself but i can imagine the following behaviour:
the check for protection in oak is built on top of the Oak API which already enforces permissions while afaik the same in jackrabbit would operate on the item states, which were not access controlled.

we found similar problems before in the oak-jcr layer and i wouldn't be surprise if there was yet another one :-)

may i kindly ask you to file a JIRA issue with a description on how to reproduce the issue. even better if you could attach a simple test-case that illustrates the problem.

for the latter you may extend from AbstractJcrTest (from the tck) or from AbstractEvaluationTest present in oak-jcr.

kind regards
angela 

On 24/04/15 16:13, "Lemes, Fernando" <fe...@hp.com> wrote:

>
>   Hi guys,
>
>   I'm dealing with some access control problems trying to migrate a 
>project from Jackrabbit 2.8.x to Oak 1.0.
>
>   I have a user1 sharing a node with user2, but the user2 cannot copy 
>that node (using session.getWorkspace().copy(<originNode>,<destNode>)
>method).. the Oak code checks if the parent for the origin node is 
>protected, but the user2 doesn't have any permission on that node. Is 
>this the expected behavior?
>
>   Regards,
>
>Fernando Lemes da Silva
>Software Engineer - Brazil R&D
>fernando.lemes@hp.com<ma...@hp.com>
>+55-11-4197-8124
>

Re: Copying nodes with access control restrictions

[Angela Schreiber <an...@adobe.com>]

hi fernando

i didn't try it out myself but i can imagine the following behaviour:
the check for protection in oak is built on top of the Oak API which
already enforces permissions while afaik the same in jackrabbit
would operate on the item states, which were not access controlled.

we found similar problems before in the oak-jcr layer and i wouldn't
be surprise if there was yet another one :-)

may i kindly ask you to file a JIRA issue with a description on how to
reproduce the issue. even better if you could attach a simple test-case
that illustrates the problem.

for the latter you may extend from AbstractJcrTest (from the tck) or
from AbstractEvaluationTest present in oak-jcr.

kind regards
angela 

On 24/04/15 16:13, "Lemes, Fernando" <fe...@hp.com> wrote:

>
>   Hi guys,
>
>   I'm dealing with some access control problems trying to migrate a
>project from Jackrabbit 2.8.x to Oak 1.0.
>
>   I have a user1 sharing a node with user2, but the user2 cannot copy
>that node (using session.getWorkspace().copy(<originNode>,<destNode>)
>method).. the Oak code checks if the parent for the origin node is
>protected, but the user2 doesn't have any permission on that node. Is
>this the expected behavior?
>
>   Regards,
>
>Fernando Lemes da Silva
>Software Engineer - Brazil R&D
>fernando.lemes@hp.com<ma...@hp.com>
>+55-11-4197-8124
>