Mon, 10 Mar 2003 16:16:02 -0500
Samuele Pedroni wrote:
> From: "Jim Fulton" <firstname.lastname@example.org>
>>Could you explain why you say that zope proxies are brittle?
> from my small experience playing with RestrictedIntepreter:
Um, er, I've been meaning to mention that RestrictedIntepreter is
not does and isn't used anywhere yet. It's a bit of a decoy
at this time. :]
At this point, RestrictedIntepreter is really an incomplete prototype.
OTOH, RestrictedBuiltins is used for Python expressions
in Zope page templates. Simple Python expressions in zpt
don't tend to run into the sorts of problems you've found.
> you wrap into proxies a lot of builtins:
> *) 'object' for example, then
> class C(object): ... does not work
Right. We will fix this. It should be possible to subclass
proxied classes. The resulting classes should then be proxies.
object and type should probably be special cases.
> but given that some basic types are left alone, one can use
> Type = ''.__class__.__class__
> class C:
> __metaclass__ = Type
> *) iter seems not to work (deliberate decision or bug?)
bug I imagine.
> *) proxied 'property' is unusable
> *) built-in functions return proxies even if the argument were unproxied:
> _12 = map(None,[1,2])
Interesting case. It looks like map shouldn't be proxied.
> class A: pass
> a = A()
> a.a = [1,2]
> _12 = getattr(a,'a')
> in both cases with the proxied version of map and getattr the result _12 would
> be a proxied list.
> deliberate safer-side decisions?
> I can see it both ways:
> - see other mail
I don't know what other mail you are refering to. Maybe it doesn't matter.
> - map(None,[obj]) becomes a way to get a a proxied version of obj that can
> be passed to code that would maybe unwrap it and believe
> that is some other legit object.
Any code that unwraps proxies should be viewed with great suspicion.
I currently consider any use of that API without an extensive accompanying
comment to be a virtual "XXX" comment.
I'm sorry to have had you spend so much time on what is a bit od a decoy.
OTOH, you've pointed out a number of points that we do need to address to
move our RestrictedInterpreter beyond the prototype stage.
You've found a number of problems and issues in deciding how to proxy
builtins. I would argue that these are not problems in the proxies
themselves but in the applications to builtins. But perhaps I'm wrong.
Another area that we haven't dealt with yet is how proxies will work in
untrusted *persistent* modules. But you probably don't want to know
about that. ;)
Jim Fulton mailto:email@example.com Python Powered!
CTO (888) 344-4332 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org