jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <mdue...@apache.org>
Subject Re: NodeDelegate leakage from NodeImpl
Date Wed, 13 Jun 2012 07:55:58 GMT


On 13.6.12 8:04, Thomas Mueller wrote:
> Hi,
>
>> This defeats the original intent of the
>> separation of NodeImpl and NodeDelegate (OAK-84)
>> users should not be able to gain access to internals by hacking NodeImpl.
>
>
> Hm, is this a security problem? Do we want to protect the data from users
> of the JCR API?

No, its about making it as difficult as possible to mess things up by 
using internals. I.e. its about avoiding the

   ((NodeImpl) node).messWithMe();

pattern.

Michael


>
> Or do we want to protect the data within the Oak implementation (use a
> better abstraction)?
>
>> But precisely this
>> is now possible when a user put his code into the
>> org.apache.jackrabbit.oak.jcr package.
>
> A attacker could always use reflection (setAccessible(true)). If we want
> real protection, we would have to enforce using a SecurityManager. Then we
> could seal the package [1]
>
> [1] http://docs.oracle.com/javase/tutorial/deployment/jar/sealman.html
>
> Regards,
> Thomas
>
>
>
>
>
>
>
> On 6/7/12 1:07 PM, "Michael Dürig"<michid@gmail.com>  wrote:
>
>>
>> Hi,
>>
>> I noticed that since revision 1344662 NodeImpl has an (package private)
>> accessor for NodeDelegate. This defeats the original intent of the
>> separation of NodeImpl and NodeDelegate (OAK-84): users should not be
>> able to gain access to internals by hacking NodeImpl. But precisely this
>> is now possible when a user put his code into the
>> org.apache.jackrabbit.oak.jcr package.
>>
>> Michael
>>
>>
>

Mime
View raw message