![](https://secure.gravatar.com/avatar/3b7e6c77a5412587152c9e3f22b41c2a.jpg?s=120&d=mm&r=g)
Following-up to my own post in order to apologize for contributing to the tradition of confusing restricted execution with rexec. I, Zooko, wrote:
2. Mandatory private data (accessible only by the object itself). Normal Python doesn't have mandatory private data. If I understand correctly, both rexec and proxies (attempt to) provide this. They also attempt to provide another safety feature: a wrapper around the standard library and builtins that turns off access to dangerous features according to an overridable security policy.
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
![](https://secure.gravatar.com/avatar/047f2332cde3730f1ed661eebb0c5686.jpg?s=120&d=mm&r=g)
[Zooko]
2. Mandatory private data (accessible only by the object itself). Normal Python doesn't have mandatory private data. If I understand correctly, both rexec and proxies (attempt to) provide this. They also attempt to provide another safety feature: a wrapper around the standard library and builtins that turns off access to dangerous features according to an overridable security policy.
[Zooko, responding to himself]
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?
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