
Following-up to my own post in order to apologize for contributing to the tradition of confusing restricted execution with rexec. I, Zooko, wrote:
Perhaps it is that "restricted execution" is designed to provide private data, by disabling certain introspection features, and "rexec" and "proxies" are designed to provide the wrapper feature? Regards, Zooko

[Zooko]
[Zooko, responding to himself]
Not really. Restricted execution doesn't provide private data in general: all instance variables of all user-defined classes are accessible to restricted code. However, restricted execution prevents introspection paths that can lead from a function or bound method to its globals or object, respectively, thereby effectively turning functions and bound methods into capabilities. Security proxies can be used to enforce private data, however. The "rexec" module is used to wrap the standard library. Its approach is the following, implemented by overriding __import__: - For modules written in Python, it gives the untrusted code a separate copy of the module, so that the untrusted code can't mess with module globals that might have a meaning to the trusted kernel. - For extension modules (i.e. modules written in C), it has a list of trusted modules, it provides wrappers for some others that only allow a safe subset, and all others are completely off limits. It also wraps open() and a few other built-ins. --Guido van Rossum (home page: http://www.python.org/~guido/)

[Zooko]
[Zooko, responding to himself]
Not really. Restricted execution doesn't provide private data in general: all instance variables of all user-defined classes are accessible to restricted code. However, restricted execution prevents introspection paths that can lead from a function or bound method to its globals or object, respectively, thereby effectively turning functions and bound methods into capabilities. Security proxies can be used to enforce private data, however. The "rexec" module is used to wrap the standard library. Its approach is the following, implemented by overriding __import__: - For modules written in Python, it gives the untrusted code a separate copy of the module, so that the untrusted code can't mess with module globals that might have a meaning to the trusted kernel. - For extension modules (i.e. modules written in C), it has a list of trusted modules, it provides wrappers for some others that only allow a safe subset, and all others are completely off limits. It also wraps open() and a few other built-ins. --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (2)
-
Guido van Rossum
-
Zooko