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:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
