Re: svn commit: r512695 - in /jackrabbit/trunk/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/commons: AbstractItem.java AbstractNode.java AbstractProperty.java

[Jukka Zitting <ju...@gmail.com>]

Hi,

On 2/28/07, Marcel Reutegger <ma...@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

Re: svn commit: r512695 - in /jackrabbit/trunk/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/commons: AbstractItem.java AbstractNode.java AbstractProperty.java

[Jukka Zitting <ju...@gmail.com>]

Hi,

On 3/2/07, Stefan Guggisberg <st...@gmail.com> wrote:
> On 3/2/07, Jukka Zitting <ju...@gmail.com> wrote:
> > 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.

Fair enough. :-)

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

I guess that's valid. I'll add a note about this and an extra catch
for the AccessDeniedException in the abstract base classes I've been
drafting. I figure all reasonable subclasses would override those
default method implementations in any case, so this shouldn't be much
of a problem.

BR,

Jukka Zitting

Re: svn commit: r512695 - in /jackrabbit/trunk/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/commons: AbstractItem.java AbstractNode.java AbstractProperty.java

[Stefan Guggisberg <st...@gmail.com>]

On 3/2/07, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> On 2/28/07, Marcel Reutegger <ma...@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.

cheers
stefan

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