recursion-safe permission policies

[Christian G. Warden]

Is there a recommended way of implementing IPermissionPolicy such that
multiple policies don't cause infinite recursion? I'm writing a
simple policy similar to SensitiveTicketsPolicy that requires a new
permission in order to view sensitive components, and I would like to
use it in combination with PrivateTicketsPolicy.

The problem is evident when enabling SensitiveTicketsPolicy and
PrivateTicketsPolicy. The former checks for the VIEW_SENSITIVE
permission, which causes PrivateTicketsPolicy's check_permission to be
called. PrivateTicketsPolicy, in turn, checks for its permissions,
which causes SensitiveTicketsPolicy's check_permission to be called,
until maximum recursion depth is hit.

Is there a cleaner solution than having my policy explicitly ignore
the PrivateTicketsPolicy permissions?

Thanks,
Christian

[Christian Boos]

I don't know those plugins, but assuming they're working in a similar
way to the vulnerability_tickets.py sample plugin, I tried to imagine a
way through. The perm and resource objects are both non-extensible
objects (their class is using the __slots__ mechanism), so you can't
attach a marker there to indicate that you're re-entering your
permission policy. So one way (apart from looking directly through the
call stack...) would be to create a Thread.local dictionary (or set) and
keep note there of the resources you've already started to check, so
that you can avoid recursion.

Of course, in future versions of the permission API, we could add a
mechanism for avoiding such issues, or at least make it easier for
permission policies to detect such situations.

-- Christian