[Cubicweb] Notes about the localperms cube
Aurélien Campéas
aurelien.campeas at logilab.fr
Fri Dec 20 15:34:46 CET 2013
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.
More information about the Cubicweb
mailing list