This module contains the RExec class, which supports
r_eval(), r_execfile(), r_exec(), and
r_import() methods, which are restricted versions of the standard
Python functions eval(), execfile() and
the exec and import statements.
Code executed in this restricted environment will
only have access to modules and functions that are deemed safe; you
can subclass RExec to add or remove capabilities as desired.

Warning:
While the rexec module is designed to perform as described
below, it does have a few known vulnerabilities which could be
exploited by carefully written code. Thus it should not be relied
upon in situations requiring ``production ready'' security. In such
situations, execution via sub-processes or very careful
``cleansing'' of both code and data to be processed may be
necessary. Alternatively, help in patching known rexec
vulnerabilities would be welcomed.

Note:
The RExec class can prevent code from performing unsafe
operations like reading or writing disk files, or using TCP/IP
sockets. However, it does not protect against code using extremely
large amounts of memory or processor time.

hooks is an instance of the RHooks class or a subclass of it.
If it is omitted or None, the default RHooks class is
instantiated.
Whenever the rexec module searches for a module (even a
built-in one) or reads a module's code, it doesn't actually go out to
the file system itself. Rather, it calls methods of an RHooks
instance that was passed to or created by its constructor. (Actually,
the RExec object doesn't make these calls -- they are made by
a module loader object that's part of the RExec object. This
allows another level of flexibility, which can be useful when changing
the mechanics of import within the restricted environment.)

By providing an alternate RHooks object, we can control the
file system accesses made to import a module, without changing the
actual algorithm that controls the order in which those accesses are
made. For instance, we could substitute an RHooks object that
passes all filesystem requests to a file server elsewhere, via some
RPC mechanism such as ILU. Grail's applet loader uses this to support
importing applets from a URL for a directory.

If verbose is true, additional debugging output may be sent to
standard output.

It is important to be aware that code running in a restricted
environment can still call the sys.exit() function. To
disallow restricted code from exiting the interpreter, always protect
calls that cause restricted code to run with a
try/except statement that catches the
SystemExit exception. Removing the sys.exit()
function from the restricted environment is not sufficient -- the
restricted code could still use raise SystemExit. Removing
SystemExit is not a reasonable option; some library code
makes use of this and would break were it not available.