[Python-Dev] Adding a builtins parameter to eval(), exec() and import().

Fri Mar 9 00:26:32 CET 2012

On 07/03/2012 16:33, Mark Shannon wrote:
> It should also help with sandboxing, as it would make it easier to
> analyse and thus control access to builtins, since the execution context
> of all code would be easier to determine.

pysandbox patchs __builtins__ in:
 - the caller frame
 - the interpreter state
 - all modules
It uses a read-only dict with only a subset of __builtins__. It is 
important for:
 - deny replacing a builtin function
 - deny adding a new "superglobal" variable
 - deny accessing a blocked function
If a module or something else leaks the real builtins dict, it would be 
a vulnerability.
pysandbox is able to replace temporary __builtins__ everywhere and then 
restore the previous state.
Can you please explain why/how pysandbox is too restrictive and how your 
proposition would make it more usable?
> Currently, it is impossible to allow one function access to sensitive
> functions like open(), while denying it to others, as any code can then
> get the builtins of another function via f.__globals__['builtins__'].
> Separating builtins from globals could solve this.

For a sandbox, it's a feature, or maybe a requirement :-)
It is a problem if a function accessing to the trusted builtins dict is 
also accessible in the sandbox. I don't remember why it is a problem: 
pysandbox blocks access to the __globals__ attribute of functions.
Victor

[Python-Dev] Adding a builtins parameter to eval(), exec() and __import__().

[Python-Dev] Adding a builtins parameter to eval(), exec() and import().