Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Received-SPF: pass (nike.apache.org: domain of anchela@adobe.com designates
 64.18.1.187 as permitted sender)
From: Angela Schreiber <anchela@adobe.com>
To: "oak-dev@jackrabbit.apache.org" <oak-dev@jackrabbit.apache.org>
Date: Thu, 26 Sep 2013 13:59:59 +0100
Subject: Re: Workspace#copy with referenceable nodes
Thread-Topic: Workspace#copy with referenceable nodes
Thread-Index: Ac66uFEU8HjmYApwRRiPHrOckSLj8w==
Message-ID: <CE69F975.90CB%anchela@adobe.com>
In-Reply-To: 
 <9C0FC4C8E9C29945B01766FC7F9D389818A74DA9BA@eurmbx01.eur.adobe.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.3.2.130206
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

hi marcel

ok, that's another way of looking at it. i somehow expected
the copy to be performed on the complete tree defined by
the specified source.

but you are right, if the permissions were be inherited from
an ancestor node, the result of the copy might expose information
that was not accessible before. as it can also happen, that they
are no longer accessible at the destination although the
source was accessible (think of some wild card restrictions).

however, if the access rights were part of the copied tree a
full copy would IMO result in the same access rights.

in addition i wonder what happens if the original source tree
contains intermediate nodes that were not accessible but
the subtrees were again... wouldn't that qualify as well as
being part of the subtree of the source that needs to be copied?
we would not get these copied with the current approach.

kind regards
angela


On 9/26/13 11:43 AM, "Marcel Reutegger" <mreutegg@adobe.com> wrote:

>Hi,
>
>> 1) Root#copy
>> 2) Traverse the tree and set new jcr:uuid properties
>> 3) Update references
>>=20
>> IMO this fix is not correct and will not work because it's not built
>> on the nodestate level. The latest root used for the copy will
>> only see those items accessible to the editing session (i.e. permission
>> constraints are enforced).
>
>but you wouldn't want to copy items you don't have access to, right?
>the current oak implementation simply copies what is accessible by
>the editing session. anything else seemed wrong to me and will
>leak information not accessible to the editing session.
>
>> similarly the editing session is not guaranteed to see all (weak)
>> reference properties in the copied subtree and again the contract
>> defined by the specification cannot be met.
>
>my interpretation of the contract was from the editing session POV.
>if the editing session does not see a weak reference, then it is simply
>not copied and becomes a non-issue. on the other hand if the
>editing session does not have access to referenced node, then there
>is no reason to update the weak reference. because per specification
>the referenced node is not within the scope of the copied subtree
>and the reference is dangling as it was before.
>
>the situation with regular references is a bit different and I think there
>we actually need to do something more. a node of a copied sub-tree
>may reference a node not accessible to the editing session. right now
>it simply copies the dangling reference, but I think it would be better
>to fail the operation in this case.
>
>> what is needed IMO is a low-level copy within the Root#copy call
>> which can get access to all jcr:uuid properties and all (weak)
>>references
>> present in the copied tree.
>
>I don't think this will work. either only the items accessible to the
>editing session is copied or the operation will leak information the
>editing session is not allowed to see.
>
>regards
> marcel
>