Dylan, I'm sure if we're on the same page or not. Perhaps it would help to more fully explain the situation. I spoke of 'Viewer' and 'Editor' (actually I'm recycling 'Owner') roles. On my root folder, these are loosely mapped to the 'View' and 'Edit' privileges, respectively. Almost all of my methods are restricted to one of these two privileges using declareProtected(). In order to granularly assign permissions to particular users on particular objects, I add local roles to each object, mapping a particular user to a role. The problem comes in when Zope combines the explicit local roles with any local roles granted on all parent objects, effectively granting a user more roles than it ought. I understand that you can assign default privileges to a particular role programmatically. Concerning setPermissionDefault(), the documentation says "Note that it is not always necessary to use this method. All permissions for which you did not set defaults using setPermissionDefault are assumed to have a single default role of Manager." This said, I'm not sure how adding this into my product code will prevent the "trickle down" local role effect. Nathaniel Dylan Reinhardt <zope@dylanreinha To: nwingfield@che-llp.com rdt.com> cc: Zope Users <zope@zope.org> Subject: Re: [Zope] Local Roles and Acquisition 09/09/2003 11:36 AM Please respond to zope On Tue, 2003-09-09 at 07:59, nwingfield@che-llp.com wrote:
In this situation, I do not wish for local roles to be acquired from above. In other words, I don't want Joe to acquire the local role of 'Viewer' when attempting to look at Sam's stuff.
OK. That's easy enough to specify.
Because Zope makes the bold assertion that security should always get
more
permissive the deeper one traverses the object hierarchy,
It does? Maybe we have different definitions of "deeper" but I think that standard practice is exactly the opposite of what you describe.
is there no way to do this short of hacking the 'getRolesInContext()' method?
Sure. Use security assertions in your product code to limit viewing-related privileges to owner and manager by default. Unless I'm grossly misunderstanding the question, you should be able to accomplish everything you need right in your product code. Check out this link for more info on security assertions. http://zope.org/Members/mcdonc/PDG/chap5zdg.stx HTH, Dylan
On Tue, 2003-09-09 at 09:47, nwingfield@che-llp.com wrote:
I spoke of 'Viewer' and 'Editor' (actually I'm recycling 'Owner') roles. On my root folder, these are loosely mapped to the 'View' and 'Edit' privileges, respectively. Almost all of my methods are restricted to one of these two privileges using declareProtected().
OK.
The problem comes in when Zope combines the explicit local roles with any local roles granted on all parent objects, effectively granting a user more roles than it ought.
I'm not sure that's the only problem. It's easy enough to restrict acquisition of permissions. I think a bigger problem may be that you are defining roles coarsely. With only one editor role, it's going to be difficult to distinguish between "editor in one context" and "editor in another context". At a minimum, this sounds like a three-role system: - Viewer - Owner (default Editor) - Guest Editor If I understand you, everyone can view and owners can edit. On certain objects, you want to enable "guest" (non-owner) editing. To do this, create the GuestEdit role at the highest level it should apply and add it to the correct users' roles. If you want your guest editor list to be same for all objects that enable guest editing, you're pretty much done: just enable guest editing per object desired. On the other hand, if you want to define *who* has the guest edit role per object, that's going to be a lot more work. The standard way to do that would be to create a role for each desired permutation. :-) Depending on how many users and objects we're talking about, it may be worth thinking about creating a root-level method that has an Editor proxy role. This method could have one large mapping containing each object each user should be able to guest edit (or vice versa). Basic object permissions for inner objects are configured strictly and this method allows users to "pierce" the security for objects they should have greater access to. This solution isn't necessarily easy or foolproof, but might be worth considering if you're talking about a really large system with many different combinations of editors and objects. HTH, Dylan
participants (2)
-
Dylan Reinhardt -
nwingfield＠che-llp.com