jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Re: Rethinking access control evaluation
Date Sat, 05 Oct 2013 03:31:22 GMT

On Fri, Oct 4, 2013 at 8:29 PM, Tobias Bocanegra <tripod@apache.org> wrote:
> that's exactly the new algorithm Angela is working on right now


> However, it's not so simple since we also need to consider higher
> level ACEs with restrictions. I.e. even if you know there are no more
> ACLs beyond a specific node, there could still be a an earlier ACE
> with a restriction that matches an item path further down.

A few years ago in Apache Tika I solved a structurally similar problem
with a state machine. The idea, applied to Oak, would be to model the
effect of ACEs as state machines that switch from one state to another
as we descend down the tree. Something like this:

    interface EffectivePermission {

         * Returns the effect of this permission on the specified child node,
         * or {@code null} if this permission does not apply to that subtree.
        EffectivePermission getPermissionForChildNode(
            String name, NodeState state);


The effect of a normal ACE that applies to the entire subtree would
remain unchanged for all descendants:

    public EffectivePermission getPermissionForChildNode(
            String name, NodeState state) {
        return this;

An ACE that's limited to just the node on which it was defined, would
have no effect on descendants:

    public EffectivePermission getPermissionForChildNode(
            String name, NodeState state) {
        return null;

More complex restrictions (glob patterns, type matches, etc.) can be
implemented with this same pattern. As an example, the mentioned
solution in Tika implements a fairly complete XPath subset using this
approach: https://github.com/apache/tika/tree/trunk/tika-core/src/main/java/org/apache/tika/sax/xpath.

> Also keep in mind, that the performance of the algorithm really
> depends on the ACL distribution. for example, repositories with very
> restrictive ACLs on every "document" would benefit from the bottom-up
> approach. So I think that we need both and find a way to choose the
> strategy automatically or by configuration.

Do we have real-world examples of such ACL-heavy repositories? Do they
also require optimum performance? I'm not aware of any such use cases,
but that of course doesn't mean they don't exist.

If possible I'd rather avoid the extra complexity and go with just a
single strategy that's optimized for the kinds of repositories we
normally see.


Jukka Zitting

View raw message