jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting" <jukka.zitt...@gmail.com>
Subject Re: svn commit: r512695 - in /jackrabbit/trunk/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/commons: AbstractItem.java AbstractNode.java AbstractProperty.java
Date Fri, 02 Mar 2007 09:30:12 GMT
Hi,

On 2/28/07, Marcel Reutegger <marcel.reutegger@gmx.net> wrote:
> according to the spec Item.getPath() is different in this respect. that is, you
> can get the path of an item even though an ancestor of an item is not 'visible'
> to you. I put visible in quotes because at least the name of the ancestor
> where a session does not have read right is disclosed.

Looking deeper into this I find it curious that AccessDeniedException
is declared for Item.getParent() and Item.getAncestor(), but not for
things like Session.getItem(). I assume this is because throwing an
AccessDeniedException from Session.getItem() would actually expose the
fact that such an item exists, and thus it is more correct to throw a
PathNotFoundException. However, with Item.getParent() or
Item.getAncestor() the existence of the parent or ancestor node is
already known, so throwing an exception doesn't seem to serve any
security purpose.

The only thing being protected is that the client will not have a
reference to a parent or ancestor node. I could always construct a
custom Node instance myself that would act just like such a  parent or
ancestor node would, throwing AccessControlExceptions for all attempts
to access property, child node, or metadata information. How would
such an instance differ from something that Item.getParent() or
Item.getAncestor() can't return?

> well, I guess this is just a detail...

An interesting detail, as it exposes some of the underlying access
control assumptions in JCR... Perhaps a topic to take up at the
JSR-283 EG.

BR,

Jukka Zitting

Mime
View raw message