[Zope3-dev] security frustrations

[Martijn Faassen]

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