[Cubicweb] Notes about the localperms cube

Sylvain Thénault sylvain.thenault at logilab.fr
Thu Dec 19 19:17:35 CET 2013


thanks for taking the time to share your though on this. Here are some more
information and questions. 

On 19 décembre 17:52, Aurélien Campéas wrote:
> The bad parts
> .............
> * the downside of flexibility is complicatedness, which makes it
>   difficult to properly use
>   It is specially difficult to debug any error while constructing a
>   security policy with it.
>   The global O_RELS/S_RELS sets contain all the propagation paths of
>   all clusters. The names are confusing and do not help guessing which
>   one to use (having to think about roles is just error-prone in this
>   context).

I definitly agree S_RELS / O_RELS should have better name or exposed through a
nicer API.
> * 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.

> * There is probably one costly join performed for each security check:
>     X require_permission P, P name "developper", U has_group_permission P
>   There's no reason (that I can see at least) not to have e.g.:
>     U can_update X

no reason beside performance, which remains the pb in such relation-propagation
based feature. Anyway, notice this is almost impossible to do in the localperms
cube, it musts be done at the application level.
> Possible enhancements
> .....................
> There should be a closed set of permission names, e.g. carried in a
> vocabulary, to help the developpers and the poor admins.

As localperm may be used by several cube, permission names can't be constrained
beside in a top-level application cube.
> There should be automatically derived `U can_read X`, `U can_update
> X`, etc. relations for the security implementor to use in the rql
> expressions. The flexibility of localperms allows that. It may be
> considered too write-costly (massive data imports would obviously
> suffer) however.

See above note.

> The propagation path definition API should be more structured and
> helpful. It is basically about defining a subgraph with special nodes
> (those with the granted_permission relation). Defining subgraphs for
> whatever reason (e.g. notification as with the nosylist cube) is in
> itself an important activity that should (maybe) be made clear & easy
> to handle, and certainly we can do better than populate a couple of
> global sets with relation type names.
> There should also be abundant documentation on how to go TDD with
> this.

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

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

>   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 ;)

> 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. Also, the
forthcoming RQL rewrite feature may help here.

Sylvain Thénault, LOGILAB, Paris ( - Toulouse (
Formations Python, Debian, Méth. Agiles: http://www.logilab.fr/formations
Développement logiciel sur mesure:       http://www.logilab.fr/services
CubicWeb, the semantic web framework:    http://www.cubicweb.org

More information about the Cubicweb mailing list