Guido van Rossum wrote:
I'm told that proxies actually rely on rexec, too. So, I guess whichever approach you take, you need rexec.
Yes and no. It's unclear what *you* mean when you say "rexec". There is a standard module by that name that employs Python's support for tighter security and sets up an entire restricted execution environment. And then there's the underlying facilities in Python, which allow you to override __import__ and all other built-ins; this facility is often called "restricted execution." Zope security proxies rely on the latter facilities, but not on the rexec module.
I suggest that in order to avoid confusion, you should use "restricted execution" when that's what you mean, and use "rexec" only to refer to the standard module by that name.
OK, I mean restricted execution.
The problem is that although you can think about proxies as being like a segmented architecture, you have to enforce that segmentation. And that means doing so throughout the interpreter, doesn't it? I suppose it might be possible to abstract things in some way to make that less widespread, but probably not without having an adverse impact on speed.
The built-in restricted execution facilities indeed do distinguish between two security domains: restricted and unrestricted. In restricted mode, certain introspection APIs are disallowed. Restricted execution is enabled as soon as a particular global scope's __builtins__ is not the standard __builtins__, which is by definition the __dict__ of the __builtin__ module (note __builtin__, which is a module, vs. __builtins__, which is a global).
Oh, I understand that, but the complaint was that it is spread all over the interpreter. One of the nice thing about hardware enforced segmentation is that you have a high assurance that it really is segemented. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff