[Zope3-dev] Re: security frustrations

[Florent Guillaume]

Does it work to just set __parent__ to the container? Or does the 
zopesecuritypolicy require more accurate context?

Florent


Martijn Faassen wrote:
> Hi there,
> 
> In working with Zope 3 to build an application, I repeatedly run into 
> the following situation:
> 
> * user gets a local role on a container
> 
> * object is created
> 
> * after object creation but before the object is added,
>   various things are done to the object.
> 
> * authorization error: user cannot access various attributes.
> 
> Now, the user would've had access to this after the object is added to 
> the container, as then the role would've been acquired. In this latest 
> the container the object is added to is actually *dependent* on the 
> state of the object, though. Besides, sometimes one wants to mess with 
> object attributes *before* adding it and thus getting it, say, cataloged.
> 
> Now in Zope 2 this is:
> 
> * normal as everything needs to be acquisition wrapped
> 
> * not a problem as filesystem code is trusted
> 
> In Zope 3, filesystem code is not trusted, and now this actually bites 
> me more than it ever did in Zope 2.
> 
> This is frustrating. I can hack around it by sprinkling 
> removeSecuritProxy throughout the codebase, but that's certainly not 
> pretty. Zope 3 is usually very nice about context not being dependent on 
> location (I see now why getSite() is very nice), but the security case 
> is an exception.
> 
> I don't have a concrete proposal about what should be done. I guess the 
> paradox is that on the one hand I *want* acquisition of role information 
> from the container (as the security model this application has is quite 
> involved), and on the other hand I keep getting bitten by it.
> 
> My problem is only with zopesecuritypolicy. At first I thought about 
> implementing my own security policy for this application, but this got 
> quickly very hairy, so I decided to stick to Zope's.
> 
> I guess this also ties in to Steve Alexander's ongoing campaign against 
> location (as opposed to site) dependence in Zope 3. Maybe he has a 
> better idea how to resolve this...
> 
> Regards,
> 
> Martijn


-- 
Florent Guillaume, Nuxeo (Paris, France)   CTO, Director of R&D
+33 1 40 33 71 59   http://nuxeo.com   fg at nuxeo.com