I've further enhanced yesterday's patch with the following additions: * "Short-circuit evaluation" of local roles in User.getRolesInContext(). This speeds up security evaluation for complex DTML by stopping the local role search as soon as one of the desired roles is found. The change is fully backward compatible with any other usage of getRolesInContext() (although there *arent'* any other usages in the Zope core). (Note: this change also prevents infinite recursion of local roles lookup when the local roles are provided by a ZPatterns attribute provider which is owned by a user who has the necessary roles to compute local roles.) * Encapsulation fix. The current version of Zope directly accesses __ac_local_roles__ when checking access rights, which negates any ability for Zope objects to provide rule-based local roles without computing all possible roles for all possible users. * Added "get_local_roles_for_user()" method to AccessControl.Role.RoleManager that works with a user object, rather than a user name. This is to allow objects to supply computed local roles using attributes of the user as part of their decision process. An object need only implement get_local_roles_for_user(user,roles) to carry this out. These additions, in conjunction with the ability to add more users to the "access" file, will allow ZPatterns and LoginManager to do without 'unownedness' and other convoluted alterations of the Zope security model. They will also make it possible to add local role plugins to ZPatterns. This is somewhat more tested than yesterday's variant of the patch, although I have not found any bugs in what I posted yesterday. The post itself was flawed, however; this time I'm attaching it as a file in the hopes of preventing that happening again. If there are no comments/questions/feedback on it, I'd like to go ahead and submit it to the Collector for inclusion in Zope CVS; as it will make continued development of ZPatterns and LoginManager much cleaner and in full compliance with the 2.2 security model. As I move further into the development of local role plugin support for ZPatterns, I may have additional patches to suggest, as there are some other encapsulation/interface issues with the "get_local_roles()" method as currently used/implemented in Zope. Most likely, there needs to be a "get_users_with_local_role()" method for those uses, leaving "get_local_roles()" to mean "get *editable* local roles". Also, ObjectManager still inspects __ac_local_roles__ rather than going through an interface to set the initial owner role of an object. Personally, I think this should be done by one of the many other after-add type calls such as manage_afterAdd or manage_fixupOwnershipAfterAdd, etc., but backward compatibility for that would be tricky. Patch follows.