[Zope3-dev] security frustrations

[Jim Fulton]

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.

How is the new object being security proxied?  Is it being created
by a security proxied factory? Generally, new objects aren't
proxied in the first place.

> 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,

It is trusted, but not as far as it was in Zope 2.  It can import
anything it wants and this has access to lots of unproxied objects,
uncluding utilities.  It does get proxied data passed to it from
untrusted code.

 > 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.

No, but, done in moderation and with care, it is at least explicit.

 > 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'm still puzzled why new objects are being proxied in the first place.

> 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.

FWIW, we will (soon I hope) be releasing a new security policy that doesn't
use acquisition nearly as much.  In partiocular, for objects that that can
have security assertions, it doesn't acquire security assertions.  I'm not
sure that will help you because you still have to actually make the assertions
on the new objects and, if the object is security proxied, then the you won't
have permission to make the assertions. :)

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org