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"<[email protected]> 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
