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 mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
