[Cubicweb] Notes about the localperms cube

Aurélien Campéas aurelien.campeas at logilab.fr
Thu Jan 2 13:58:28 CET 2014

On 20/12/2013 15:34, Aurélien Campéas wrote:
>>> * doing security with container leads to security rules of the
>>>   following kind:
>>>   ERQLExpression('X root R, U can_read R') # etype
>>>   and the security of the relations will be handled _automatically_
>>>   once a specific set of declarations have been made. Switching back
>>>   to manual mode is also supported for the relations that need it.
>> I don't get what 'automatically' / manual mode means here.
> This is the key productivity booster.
> Hand-writing the same rules (except for role guess game -- i.e. is S
> or O the entity nearest to the root/cwpermission ? -- in which you
> always loose the first time) all over the cluster is tedious and error
> prone.
> The insight is that a default policy is what people want in their
> clusters. So providing a permission _function_ to a container-walking
> function that will annotate the proper __permission__ (in a
> post_build_callback) for you is a great boon.
> The security-container api offers an escape from this automation and
> it is perfectly possible to put custom __permissions__ that won't be
> overridden if you use the provided helpers.

Just going to say the same thing, with slightly different words and
some pointers.

I have observed that many security specs can be expressed as:

* a default or background policy
* ad-hoc/well structured exceptions

The automatic weaving of __permissions__ provides the first item
with an O(1) cost instead of O(container schema).

The secutils.py module of container provides an API for background
policy/ad-hoc exceptions. The code is structured in a way that should
not preclude people making their own security-weaving logic.

See the long explanation here:


The secutils module here:



More information about the Cubicweb mailing list