Hi, In using the declarative security framework, I fell to the typo trap and created another permission. After countless hours debugging zope, and tracking down why my site suddenly became offlimits to anyone but Managers, I finally nailed it. I had declareObjectProtected to a permission that was almost, but not quite, entirely unlike 'Access contents information'. But, alas, inside ZMI, the old and incorrect permission is still there, even though there is nothing else being protected by it. I restarted zope a couple of times but the permission was still there. But while I was writing the above paragraphs the litle voices inside my head told me in a hushed tone: 'Try stopping the zeo server...' Yes! ZEO is so painless that I almost forgot I was using a single machine ZEO configuration with two ZEO clients in different ports so that I could use a single browser with two different logins. So I stopped both clients and the zeo server and restarted them and the rogue permission was gone. I'd like to take this opportunity to thank Ken Manheimer for the Handy Emacs Gadgets at http://www.zope.org/Wikis/klm/EmacsGoodies, specially for the PDBtracker, which made debugging zope bearable. I'm still looking for a satisfatory way of running zope under ddd or the Idle debugger though. Pdb still lacks a 'display'-like function (to evaluate certain expressions whenever the debugger prompts) and Zope debug hooks bypass pydb (ddd) and the Idle debugger straight into Pdb proper. And speaking of debugging, it is really hard to debug permission problems in Zope. A lot harder than I thought it would be, and I like to think that I am used to hard debugging sessions. I have experience debugging C programs with only gdb, before I learned the wonders of running gdb under emacs or ddd. I still have nightmares from those experiences :-) Anyway, after seeing the permission system working from the browser point of view and from the declarative security of Python Products point of view, and even seeing some examples of __ac_permissions__ structures, I never thought that permission checking in zope would be so convoluted. The dynamically calculated __roles__ attribute gave me a still lingering headache :-) Also, can anyone explain to me why access should be denied if aq_base(container) equals getattr(accessed, 'aq_base', container) when other checks fail? (check lib/python/AccessControl/ZopeSecurityPolicy:ZopeSecurityPolicy.validate() to understand what I mean). In any event, it should be easier to be able to determine what permissions an user should have and what permissions she actually has, when confronted with an 'Unauthorized' or a 'Permission Denied' error. It is particularly troubling not being able to divine where the code jumps to from the call to roles=getattr(value, '__roles__', _noroles) at line 125 in the aforementioned file (as of Zope 2.4.1). Ok, enough rambling for now :-) Regards, Leo