jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Guggisberg" <stefan.guggisb...@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 10:18:25 GMT
On 3/2/07, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> 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?

it wouldn't be compliant with the spec i guess ;)

you wouldn't expect e.g. getPrimaryType() throwing an AccessDeniedExcpetion.

the jsr 170 eg's rationale for the different behaviours of Session.getItem
and Item.getParent wrt access control is as you assumed correctly:

Session.getItem throws a PathNotFound if access is denied. Item.getParent
otoh throws an AccessDeniedException in same situation since the existence
of the requested item is evident. once you have e.g. a reference to a Node
instance you should imo be able to retrieve its primary/mixin node types.


> > 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

View raw message