[Zope-dev] [Zope Enhancement Proposal] Sanitizing local roles

Tue Jul 27 09:52:46 EDT 2004

I'm very interested in all kind of enhancements to local roles. The main
use is, like you said, access-restricted subsites.

Currently I've added what I call "local roles blocking" to a few user
folders we use (CPSUserFolder, NuxUserGroups (code available on
http://cvs.nuxeo.org)) *but* there are important problems which I'll
detail below.

I use blocking of local roles in the sense that a local role specified
somewhere can either allow the role like today (it being acquired), or
block completely acquision of this role for current and deeper objects.
I guess blocking only at the exact level where the roles is present
would be a straightforward extension and wouldn't change the code much.
The spec for blocking I use is visible at
http://cvs.nuxeo.org/cgi-bin/viewcvs.cgi/NuxUserGroups/doc/BLOCKING.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup
, simply put it says that a role prefixed with '-' means that the role
is blocked instead of being granted (and acquired). We could use a
prefix of '=' to say "grant only here but don't acquire".

I'm using the standard __ac_local_roles__ datastructure to retain
backward compatibility, so an old user folder implementation would just
see additional roles with strange prefixes and wouldn't break everything
when editing them.

This works very well at the simple Zope level (indeed all the user
folder products we use have specialized version of allowed() and
getRolesInContext()).

The problems begin when we add in CMF. CMF's catalog has to manage, for
every object it indexes, an additional index called
'allowedRolesAndUsers' which is used to filter catalog objects by
viewability. This index stores all roles having the permission View in
the role/permission map, and all the users whose local role gives them
this permission.

But when you mix in groups of users and blocking, there's no way to make
this index a simple list of roles, the datastructure has to be quite
richer (mathematically, we don't have non-decreasing function of the
roles available when depth increases). This means that a KeywordIndex
cannot be used, and I have to used a specialized index whose computation
a bit more costly.

(Finally, for specialized CPS things like its object repository, this
means I have to expand local roles even more to be able to specify
arbitray complex rules for who has what permission on an object (rules
like "user foo has View, but if it's in group bar it doesn't, but if
it's in group baz it has it nevertheless").)

The visualization problem, while important, strikes me as secondary.

But the question another poster asked, what does Zope 3 do about all
this, is very important. It would be good to keep the same semantics.
The difficult part is group+blocking. But I don't know enough about Zope
3 to answer these questions.

Florent

In article <16639.63903.938767.13160 at gargle.gargle.HOWL> you write:
> Local roles are "acquired" from ancestors.
> 
> While this is not bad for e.g. a "Manager" local role,
> its conceptual usefulness is in great doubt for e.g. the "Owner" role.
> It is very unclear why an "Owner" of a folder should automatically
> be an "Owner" of all its content.
> 
> I therefore propose to make "acquisition" of local roles
> customizable.
> 
> I see two potential variants:
> 
>  1. objects get a boolean flag "__ac_acquire_local_roles__"
>     with default value "True" which allows "acquisition"
>     of all local roles.
> 
>  2. objects get a dictionary "__ac_acquire_local_roles__"
>     mapping role names to a boolean which allows acquisition
>     for the respective role.
> 
> Of course, the second variant provides more fine grained control
> and will require a more complex UI.
> 
> The change would affect the methods "allowed" and "getRolesInContext".
> of "AccessControl.User.BasicUser" and would require
> new methods in "AccessControl.Role.RoleManager" to
> read and modify the new "__ac_acquire_local_roles__".
> 
> 
> Moreover, I propose to change the local role management pages.
> When setting local roles, information about "acquired"
> local role definitions is very helpful.
> I therefore propose to display this information on the local
> role edit page.
> 
> 
> I even would prefer a much more drastic change for both
> local role management and permission-role-map management:
> a compact look only overview mapping roles to users
> and permission to roles, respectively, with links to
> a page to edit the association of a single role or permission,
> respectively. Something like:
> 
>   Role	      |  acquire |  locally assigned users| ancestor assigned users
>   -------------------------------------------------------------------------
>   Owner       |   no     |  dieter                | admin, dieter
>   -------------------------------------------------------------------------
>   Manager     |   yes    |  dieter                | admin
>   -------------------------------------------------------------------------
> 
>   The "Role" column is a link to a page to edit "acquire"
>   and "locally assigned users" for the respective role.
> 
> 
> Advantages:
> 
>  * more natural behaviour for roles like "Owner"
> 
>  * access restricted sub-sites would be much easier to implement
> 
>  * more informative management pages
> 
> 
> Risks:
> 
>  * Classes deriving from "AccessControl.BasicUser" may have
>    overridden "allowed" and "getRolesInContext".
> 
>    Such overridden methods would not interpret "__ac_acquire_local_roles__"
>    until adapted.
> 
>    Fortunately, it is not very likely that these two methods
>    are overridden.
> 
>  * Local roles get a bit more complex.
> 
>    However, explicit "acquisition" control is already used
>    for the permission role mapping. Thus, users could
>    recognize the same concept.
> 
>  * The 2.8/2.9 edition of the Zope Book would need to be adapted.
> 
> 
> If there is interest,
> I could implement the changes and provide patches
> against the Zope SVN version.
> However, I do not have write permissions to the repository.
> This means, someone else would need to make the actual checkins.
> 
> 
> BTW: Almost surely, I will implement the proposed change in our
>   "private" Zope copy and use it in one of our projects.
>   This means, I could provide "production experience" for the
>   change in some months.

-- 
Florent Guillaume, Nuxeo (Paris, France)
+33 1 40 33 79 87  http://nuxeo.com  mailto:fg at nuxeo.com