hi jukka we never have aces that effect just one single node. the effect is *always* inherited to the complete subtree unless there are additional restrictions that narrow the effect to those nodes and properties in the subtree that match a given pattern.
this is how a backwards compatible implementation must behave and i don't remember how many time i already explained this. similarly it's one of core requirements of oak that we no longer have a limitation with the number of access content entries defined in the content tree. there are in fact a lot of customers that are suffering from that limitation nowadays and it's our own product that is limited by the current shortcoming of jackrabbit. we definitely do have need for huge amount of ac content without having any performance draw back... it might well be that you are not aware of these use cases but feel asserted that they exist and that i am not going to invent use cases that make the whole story complicated if i can have it simple. one additional thing we must be aware of: SlingRepository#loginAdministrative as finally been deprecated as it's always associated with critical security issues. the replacement will be a setup with service users that have dedicated permissions. in other words: we will have a lot more access control content for all the service users and we will have long-living service user sessions that register observation listeners. this is a different situation than we have nowadays were all long-living sessions are associated with the admin session. apart from existing requirements and constraints we already have (there are quite a lot), i am also collecting use-cases for all kind of access control setup scenarios where a different access control model might be desirable underneath a given subtree of the repository. in other words: the new OAK setup must allow for custom extensions and it's very likely that we will have to add even more complexity in terms of effective policies present at a given subtree. tobi and myself had a lot of discussions during the oakathon last week regarding access control and security requirements in general. no final decisions yet... but a lot of ideas that we kept collecting over last couple of years. kind regards angela On 10/5/13 5:31 AM, "Jukka Zitting" <[email protected]> wrote: >Hi, > >On Fri, Oct 4, 2013 at 8:29 PM, Tobias Bocanegra <[email protected]> >wrote: >> that's exactly the new algorithm Angela is working on right now > >Great! > >> 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/apac >he/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. > >BR, > >Jukka Zitting
