When a Session attempts to read or update content, ModeShape needs to determine if they have privilege to do so. Prior to 3.4, the only mechanism that ModeShape supported was via JAAS roles. However, with ModeShape 3.4.0.Final, we added the ability for ModeShape to use JCR 2.0 access control lists (ACLs).
Access Control Lists
ACLs are a fine-grained mechanism for specifying the exact permissions for explicitly-named users (or groups) at a particular location in the repository. ACLs apply to the node on which they're defined and to all descendants, but when determining privileges for a particular node, the ACLs closer to the node take precedence.
ModeShape authorization mechanism takes into account both the JAAS roles and the ACL mechanism: a session must have both the proper role and (if there are applicable ACLs) permission given by those applicable ACLs. Thus, ACLs are considered a refinement of the broader roles.
For example, imagine a repository with a node at "/a/b/c" and which contains a single ACL at the parent node (e.g., "/a/b"). In order to modify properties on node "/a/b/c", a particular session must have the "read-write" role (stating that the user is able to write to the repository) and the ACL at the parent node must grant this particular user the "jcr:modifyProperties" privilege (or one of the "jcr:write" or "jcr:all" aggregate privileges). Note that ACLs do apply to all descendants, so it is possible for the ACL on the parent node to grant permissions to specific users on its children (and other descedants).
Of course, if there happens to be no ACLs on the "/a/b/c" node or its ancestors, then all privileges are implicitly granted to all users which have the required role.
This ACL feature is a technology preview in 3.4, which means that we're asking people to try it out and give us feedback, but to not yet put the feature into production. In other words, ModeShape 3.4.0.Final is ready for production, but just don't create ACLs in production repositories yet.
Repositories with no ACLs
One of the things we wanted to include in 3.4 was an optimization that completely skipped over the ACL checks in repositories that have no ACLs. (See MODE-2004 for details.) Unfortunately, I failed to merge this optimization, and it was only discovered today. That means that ModeShape 3.4.0.Final does not have this optimization, and will therefore attempt to check ACLs even if there are no ACLs in the repository.
What impact does this have on users? First of all, nothing is broken. If you are using ACLs, then those ACLs are enforced. If you are not using ACLs, then ModeShape still correctly authorizes sessions and users. But if you are not using ACLs, then ModeShape takes a bit longer with each operation to look for the non-existant ACLs. How much longer? Well, its difficult to say, since we've made some improvements in other areas, and because it completely depends on your application's access patterns. For example, if your application creates and application and does just a few operations, then it is likely the extra overhead of checking ACLs is negligent. OTOH, if your applications' sessions are doing lots of operations, then that overhead might be noticeable. If you are concerned, please check for yourself by doing some quick benchmarking of your application between 3.3 and 3.4.
Please let us know if you are concerned about 3.4 because of this. Generally we try to avoid issuing patch releases, but in this case we're willing to cut a 3.4.1 release if you want us to.
My sincere apologies for any grief or problems that I caused with this mistake!