[Cubicweb] Notes about the localperms cube

[Aurélien Campéas]

On 19/12/2013 19:17, Sylvain Thénault wrote:
[...]
>  
>> * The CWPermission provides a completely free-form "name" field, but
>>   the names are typically used hard-coded in the schema security rules
>>   (see the above rql expressions).
>>
>>   This somehow will confuse the admin which, unless she _reads_ the
>>   schema.py, can't know in advance which permissions names to use.
> 
> This is not totally true. You may define on an entity class the name of the
> permissions that make sense for it, eg:
> 
>   class Project(AnyEntity):
>     __regid__ = 'Project'
>     __permissions__ = ('developer', 'client')
>  
> That will then be used by the default security view as vocabulary.

This is the first time I see this. Now, grepping for it I find:

views.py:        permnames = getattr(entity, '__permissions__', None)

It is also mentioned in the README.

This is probably not the API we'd like to have, but indeed it exists.


[...]
>> Comparison with container + security
>> ------------------------------------
>  
>> Obviously, the differences between container and localperms are:
>>
>> * container is not primarily about security, but makes great security
>>   scopes, and provides many other features, whereas localperms is just
>>   about security,
>>
>> * the structure of a container is made of composite relations, whereas
>>   the propagation paths of localperms can be any arbitrary relations
>>   (whether this is really the case in practice remains to be seen)
> 
> May be not.

If you said "not" as in "localperms propagation paths turn out to be
composite relations", then there is great overlap between localperms
and container.

>  
>> * 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.

> 
> Also, notice a nice feature of localperms is that you can give
> permission to only a subpart of the graph.

Yes but it is also not a problem per se to introduce exceptions to
rules.

OTOH, not having rules/automation in the first place (e.g. manually
writting the __permissions__) has been shown to be quite costly.

You must realize that in the typical Pylos app, where container was
bred, they have HUGE containers, wrt etypes & rtypes, I mean it's way
beyond the tracker cube in terms of complexity, and the apps. evolve all
the time.

> 
>>   No need to say that in practice, it turned out less hard to debug &
>>   test security containers than localperms-based security models, but
>>   this is only my experience.
> 
> Being the author of the thing you debug helps ;)

It surely helps, but it is not the only reason :)

> 
>  
>> Conclusion
>> ----------
>>
>> The localperms is powerful but a bit too generic and suffer from some
>> glaring flaws. Once these are fixed, we might want to examine some
>> possibilities of convergence between the patterns of both localperms &
>> security containers.
> 
> That would be great. The last time I give a look at container, what bothered me
> is that it was hard to make it works using pre-existing application level
> relations, it has to use it's own relations even if it duplicates existing
> information. It may have been fixed since, it was some time ago.

All of the things you found annoying back then have been fixed since,
indeed (for the greatest good).

> Also, the
> forthcoming RQL rewrite feature may help here.
> 

Custom Yams annotations would help mostly.
I don't see yet where an rql rewrite rule would help.

Regards,
Aurélien.