[Zope3-dev] Bug or Feature in security proxy / checker code?

[Jim Fulton]

Martijn Faassen wrote:
> Jim Fulton wrote:
> 
>> Christian Theune wrote:
> 
> [snip]
> 
>>> Is this intentional? 
>>
>>
>> Yes.  self is never proxied.
> 
> 
> I'll just note as a data-point that this surprised me as well. I noticed 
> that some things in Zope 3 weren't giving me authorization errors as I 
> expected, even though as I was swamped in them at that point during 
> development I wasn't really regretful of that. :) I just got this 
> suspicious feeling something was off. Finally I discovered it was the 
> 'self' thing (actually, utilities you pull in aren't security proxied as 
> well).
> 
> That this is a surprise at the very least indicates that this needs to 
> be clearly documented somewhere, though perhaps it is and I missed it.

I don't think we've figured documentation out yet. We've made great progress.
There is lots of good content, but finding it isn't easy.

> It worries me a bit -- reasoning about security proxies reminds me a bit 
> too much about the reasoning about acquisition wrappers and such that I 
> have to struggle through with Zope 2. I know it worries Jim too, but he 
> says making it better needs a deep study of security usability first, 
> and I believe him. :)

I was talking about the flip side of this.  I consider usability of a security
system critical for it to be secure.  The usability I'm refering to though
is usability for end users.

The issue we're discussing here is the programming model.  Here the rules
are fairly straightforward, although applying them can certainly be complex.
Like Zope 2, Zope 3 has trusted and untrusted code.  All code on the
file system is trusted.  It has access to unproxied modules and, therefore,
ro the APIs they provide.  If you get a component, such as a utility or
adapter from these APIs, then these components are unproxied too.

Trusted code still has to deal with proxies because it is often called
from untrusted code.  Except for simple objects and certain objects it creates
itself, untrusted code generally deals with proxied objects and therefore
passes these when it calls trusted code.  If trusted code wants extra
protection, then it has to go out of it's way to get it.

BTW, the file zope/security/untrustedinterpreter.txt provides some
details on how untrusted code is treated and the rules for proxying.

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