Ben Laurie wrote:
Jeremy Hylton wrote:
...
And in either case, you also need to restrict access to the underlying libraries and (presumably) some of the builtin functions?
You don't need restricted execution to make proxies work. In Zope, we choose to use restricted execution in cases where proxies don't work well. (For example, as I mentioned in another note, we can't currently proxy exceptions.)
BTW, Guido pointed out to me that I'm causing confusion by saying "rexec" when I really mean "restricted execution".
Right. I think that there is some confusion floating around wrt proxies (not your fault :) ...
In short, it seems to me that proxies and capabilities via bound methods both do the same basic thing: i.e. prevent inspection of what is behind the capability/proxy. Proxies add access control to decide whether you get to use them or not, whereas in a capability system simple posession of the capability is sufficient (i.e. they are like a proxy where the security check always says "yes"). You do access control using capabilities, instead of inside them.
Am I not understanding proxies?
You are understanding proxies as they are *applied* in Zope. This is understandable, since the information I sent you:
http://cvs.zope.org/Zope3/src/zope/security/readme.txt?rev=HEAD&content-...
talks more about the higher-level application of proxies in Zope than about the basic proxy features.
Really, Zope proxies are on about the same level as bound methods. They are a lower-level abstraction than capabilities. YOu could use them to implement capabilities or you could use them to implement a different approach, as we have done in Zope.
As I mentioned in another Zope, I think proxies provide a better way to implement capabilities than bound methods because they provide access to objects with whole interfaces, rather than just individual functions or methods.
Jim