[Zope3-dev] Initial thoughts on the Zope3 security framework

[Guido van Rossum]

> The new pattern is:
> 
> creation:
> 
> - permissions: per-product (and there is no other way to create them)
> 
> - roles: locally (a "global" role is one defined in the root folder)
> 
>   exception - a few roles (Manager, Owner, Anonymous) are built-in.
> 
> - users: locally
> 
> mapping:
> 
> - permission-to-operation: per-product. A product doesn't know about
>   roles and users.
> 
> - role-to-permission: locally
> 
> - user-to-role: locally (via local roles).

Thanks, this is helpful (mostly confirming what I'd finally figured out).

>   In Zope 2.x it's still usual to have "global" roles for an user, but
>   they're not really global - the role holds wherever the user holds,
>   but remember the user is also local, so a role defined in the user
>   object is more or less the same as a local role on the same context.
> 
>   In Zope3 this will be deprecated. All user-to-role mappings will be
>   what we now call "local".

I'd like to learn more about how the actual permission checks are
implemented efficiently.  It seems that there must be several steps:

1. A user requests an operation on a product.  This user is
   authenticated (else it's not that user).

2. The system finds out which permission is needed for the operation;
   this is a pretty straightforward lookup on the object or method.

3. The system finds which roles have this permission, taking local
   roles into account.  This seems a relatively slow process: it has
   to backtrack up the hierarchy, and checking if there's a local
   role-to-permission mapping that affects the required permission.

4. Finally a check is made whether the user requesting the operation
   has any of the roles that provide the neede permission.  Again this
   needs to backtrack up the hierarchy, to look for local roles.

I suppose 3 & 4 can be rolled into a single backtracking routine that
shortcuts as soon as a match is found -- but it looks pretty
complicated to me.  How fast is this in practice?


My main concern however is with the enormous proliferation of
permissions, which make security management difficult: there are too
many places where a permission could be set, and it's hard to find out
(impossible AFAIK using only the ZMI!) which permissions guard which
operations.

I know Z3 tries to reduce the number of permissions by introducing
standard permissions, but there still seems to be a habit of having at
least one new permission per class...

I've been playing with the thought of making permissions into classes,
and somehow using this class hierarchy to present the ZMI view of
permissions (the Security tab) in a more concise way -- using a tree
widget corresponding to the permission hierarchy, which is collapsed
by default when all permission settings are the same in a particular
subtree.

Thoughts?

--Guido van Rossum (home page: http://www.python.org/~guido/)