On 7/23/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
OK, then using the term "namechecker" through me off.
Well, Jim said that Zope proxies didn't conform to the strict definition of object-capabilities the last time this all came about: http://mail.python.org/pipermail/python-dev/2003-March/033884.html and http://mail.python.org/pipermail/python-dev/2003-March/033915.html . He said they *could* be made to be what object-capabilities is defined as, but they were not currently structured that way. Those comments are one of the reasons I never considered thinking of Zope proxies as a object-capabilities system.
At 09:27 PM 7/23/2006 -0700, Brett Cannon wrote:
When I say "name checker" I mean the Zope type that allows you to specify a
list of names that are allowed for a given object. This allowing is not
based on identity or code signing or anything like that. It's just a list
of attribute names: i.e. a capability mask over an existing object.
When you create a proxy using this name mask, that proxy becomes a
capability that allows access to the given names on the underlying object.
OK, then using the term "namechecker" through me off.
>I like the fundemental design difference of object-capabilities
It's not a difference at all, let alone a fundamental one. Zope just
happens to allow other kinds of security checking *in addition to*
capabilities, if you want them. However, most of its more basic
encapsulation features are 100% capability based.
Meanwhile, if you want to implement an object-capability system, you will
need something that is basically a mask, to allow one piece of code to
create capabilities that can be given to another. What you end up with for
doing that is going to look almost exactly like a Zope proxy plus a Zope
name checker.
I hate to harp on this point, but there seems to be a trend that when
people have capabilities on their mind, they tend to look at Zope and
dismiss it as not being capability-based, when in fact Zope's approach is
capabilities *plus* other things.
Well, Jim said that Zope proxies didn't conform to the strict definition of object-capabilities the last time this all came about: http://mail.python.org/pipermail/python-dev/2003-March/033884.html and http://mail.python.org/pipermail/python-dev/2003-March/033915.html . He said they *could* be made to be what object-capabilities is defined as, but they were not currently structured that way. Those comments are one of the reasons I never considered thinking of Zope proxies as a object-capabilities system.
(Of course, most of those "other things" have to do with closing holes like
__subclasses__, while improving performance by still allowing lots of
common objects not to be proxied.)
OK, then I need something clarified. If you read http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/TransitionToSecurityProxies , it talks about creating the proxies. I get they restrict attribute access and wrap all returned objects in proxies themselves (unless they are considered safe). But to judge whether an attribute should be returned, it checks the security context. It also mentions how access to the security policy must be available so that proper security checks can be done to either grant or deny access.
So what I want to know is if this security context is this global thing that proxies access every time to check whether something is allowed or not. Or is it a per-object specification? And what is the security domain for Zope proxies; objects, interpreter, running Python program, what?
-Brett
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
