[pypy-dev] Zope2-RPython implementation help wanted..
chris at simplistix.co.uk
Fri Jul 18 17:28:11 CEST 2008
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.
Simplistix - Content Management, Zope & Python Consulting
More information about the Pypy-dev