GNU Info

Info Node: (python2.1-lib.info)rexec

(python2.1-lib.info)rexec


Next: Bastion Prev: Restricted Execution Up: Restricted Execution
Enter node , (file) or (file)node

Restricted execution framework
==============================

Basic restricted execution framework.

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.

_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 CPU time.

`RExec([hooks[, verbose]])'
     Returns an instance of the `RExec' class.

     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,
     e.g. using packages.)

     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.

See also:
     `Grail Home Page'{Grail is a Web browser written entirely in
     Python.  It uses the `rexec' module as a foundation for supporting
     Python applets, and can be used as an example usage of this
     module.}

RExec Objects
Defining restricted environments
An example

automatically generated by info2www version 1.2.2.9