Guido van Rossum wrote:
How is the implementation of "open" provided by the trusted code to the untrusted code? Is it possible to provide a different "open" implementation to different "instances" of the zipfile module? (I think not, as there is no such thing as "a different instance of a module", but perhaps you could have two rexec "workspaces" each of which has a zipfile module with a different "open"?)
To the contrary, it is very easy to provide code with a different version of open(). E.g.:
# this executes as trusted code def my_open(...): "open() variant that only allows reading" my_builtins = {"len": len, "open": my_open, "range": range, ...} namespace = {"__builtins__": my_builtins} exec "..." in namespace
That's fair enough, but why is it better for the "protection domain" to be an invoked "workspace" instead of an object? Think of it from a software engineering point of view: you're proposing that the right way to manage security is to override more-or-less global variables. Zooko is proposing that you pass the capabilities each method needs to that method. i.e. standard structured programming. Let's say that untrusted code wants access to the socket module. The surrounding code wants to tame it to prevent socket connections to certain IP addresses. I think that in the rexec model, the surrounding application would have to go in and poke "safe" versions of the constructor into the module. Or they would have to disallow access to the module altogether and provide an object that tamed module appropriately. The first approach is kind of error prone. The second approach requires the untrusted code to use a model of programming that is very different than "standard Python." If we imagined a Python with capabilities were built in deeply, the socket module would be designed to be tamed. By default it would have no authority at all except that which is passed in. The authority to contact the outside world would be separate from all of the other useful stuff in the socket module and socket class. I'm not necessarily advocating this kind of a change to the Python library... Paul Prescod