holger krekel wrote:

...

- something that behaves like a python function - can be pickled

this is basically about storing user-provided scripts in the zodb, right?

...or relational database, or, etc ;-)

...

- prevents people stripping security proxies from objects that are passed in to the function

hum, pypy-sandbox currently virtualizes at a low level (access to the Operating Systems files, io, etc.) and provides a *very* trustable way of running untrusted code.

Right, which is exactly what we want ;-) The security proxying is handled by a different method entirely. (The proxy objects are c extensions and prevent accessing attributes based on a pluggable set of rules) However, with access to unrestricted imports, all you'd need to do is import the unwrap method from the proxy wrapping module and you'd be fre of the jail ;-)

For providing higher and python level virtualization more work is needed so it might indeed not directly fit some use cases that RestrictedPython tries to satisfy. I am interested in this as are others, i think. Could you or someone else point to some concrete usages and use cases of the current RestrictedPython?

- Download and install Zope 2.11.1. - Add a "Script (Python)" using the Zope management interface. - Write some python code or look at the default python code that starts off in the python script. The use case is basically threefold: - general distrust of code authored through a web browser (what if someone managed to break in somehow and insert source code for a PythonSript (the things Zope calls "Script (Python)" in its management interface), etc) - provide an environment where objects that shouldn't be accessible by a particular user are filtered by the environment and where objects can also prevent their attributes from being written to or read. (the user here doesn't write code, they are running other code... as a programmer, rather than having to write security checks all the time yourself, the environment does it for you) - allow customers to write scripts where they do so in an environment where they can't access things that they shouldn't be able to, be it data, or functions like os.system, etc. There's also a "nice to have" rather than a requirement of providing an environment where code can be safely run without it accidentally consuming all memory or processing resources on a machine.

...

- prevents people importing things they shouldn't - prevents people from getting hold of un-security-proxies-objects - executes as fast as possible - each function plays in its own sandbox and can be called many many times, often simultaneously in different threads - limits the amount of memory and processor they can hog (nice to have)

the rest, i think, is quite doable, particularly limiting RAM/CPU resources.

cool :-) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk

holger krekel wrote:

...

- something that behaves like a python function - can be pickled

this is basically about storing user-provided scripts in the zodb, right?

...or relational database, or, etc ;-)

...

- prevents people stripping security proxies from objects that are passed in to the function

hum, pypy-sandbox currently virtualizes at a low level (access to the Operating Systems files, io, etc.) and provides a *very* trustable way of running untrusted code.

Right, which is exactly what we want ;-) The security proxying is handled by a different method entirely. (The proxy objects are c extensions and prevent accessing attributes based on a pluggable set of rules) However, with access to unrestricted imports, all you'd need to do is import the unwrap method from the proxy wrapping module and you'd be fre of the jail ;-)

For providing higher and python level virtualization more work is needed so it might indeed not directly fit some use cases that RestrictedPython tries to satisfy. I am interested in this as are others, i think. Could you or someone else point to some concrete usages and use cases of the current RestrictedPython?

- Download and install Zope 2.11.1. - Add a "Script (Python)" using the Zope management interface. - Write some python code or look at the default python code that starts off in the python script. The use case is basically threefold: - general distrust of code authored through a web browser (what if someone managed to break in somehow and insert source code for a PythonSript (the things Zope calls "Script (Python)" in its management interface), etc) - provide an environment where objects that shouldn't be accessible by a particular user are filtered by the environment and where objects can also prevent their attributes from being written to or read. (the user here doesn't write code, they are running other code... as a programmer, rather than having to write security checks all the time yourself, the environment does it for you) - allow customers to write scripts where they do so in an environment where they can't access things that they shouldn't be able to, be it data, or functions like os.system, etc. There's also a "nice to have" rather than a requirement of providing an environment where code can be safely run without it accidentally consuming all memory or processing resources on a machine.

...

- prevents people importing things they shouldn't - prevents people from getting hold of un-security-proxies-objects - executes as fast as possible - each function plays in its own sandbox and can be called many many times, often simultaneously in different threads - limits the amount of memory and processor they can hog (nice to have)

the rest, i think, is quite doable, particularly limiting RAM/CPU resources.

cool :-) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk