[Zope-dev] getting rid of a permission and other debugging considerations

Leonardo Rochael Almeida leo@hiper.com.br
Tue, 28 Aug 2001 15:36:12 -0300


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