Move the 2.6 reST doc tree in place.
diff --git a/Doc/library/restricted.rst b/Doc/library/restricted.rst
new file mode 100644
index 0000000..28903b7
--- /dev/null
+++ b/Doc/library/restricted.rst
@@ -0,0 +1,68 @@
+
+.. _restricted:
+
+********************
+Restricted Execution
+********************
+
+.. warning::
+
+ In Python 2.3 these modules have been disabled due to various known and not
+ readily fixable security holes. The modules are still documented here to help
+ in reading old code that uses the :mod:`rexec` and :mod:`Bastion` modules.
+
+*Restricted execution* is the basic framework in Python that allows for the
+segregation of trusted and untrusted code. The framework is based on the notion
+that trusted Python code (a *supervisor*) can create a "padded cell' (or
+environment) with limited permissions, and run the untrusted code within this
+cell. The untrusted code cannot break out of its cell, and can only interact
+with sensitive system resources through interfaces defined and managed by the
+trusted code. The term "restricted execution" is favored over "safe-Python"
+since true safety is hard to define, and is determined by the way the restricted
+environment is created. Note that the restricted environments can be nested,
+with inner cells creating subcells of lesser, but never greater, privilege.
+
+An interesting aspect of Python's restricted execution model is that the
+interfaces presented to untrusted code usually have the same names as those
+presented to trusted code. Therefore no special interfaces need to be learned
+to write code designed to run in a restricted environment. And because the
+exact nature of the padded cell is determined by the supervisor, different
+restrictions can be imposed, depending on the application. For example, it
+might be deemed "safe" for untrusted code to read any file within a specified
+directory, but never to write a file. In this case, the supervisor may redefine
+the built-in :func:`open` function so that it raises an exception whenever the
+*mode* parameter is ``'w'``. It might also perform a :cfunc:`chroot`\ -like
+operation on the *filename* parameter, such that root is always relative to some
+safe "sandbox" area of the filesystem. In this case, the untrusted code would
+still see an built-in :func:`open` function in its environment, with the same
+calling interface. The semantics would be identical too, with :exc:`IOError`\ s
+being raised when the supervisor determined that an unallowable parameter is
+being used.
+
+The Python run-time determines whether a particular code block is executing in
+restricted execution mode based on the identity of the ``__builtins__`` object
+in its global variables: if this is (the dictionary of) the standard
+:mod:`__builtin__` module, the code is deemed to be unrestricted, else it is
+deemed to be restricted.
+
+Python code executing in restricted mode faces a number of limitations that are
+designed to prevent it from escaping from the padded cell. For instance, the
+function object attribute :attr:`func_globals` and the class and instance object
+attribute :attr:`__dict__` are unavailable.
+
+Two modules provide the framework for setting up restricted execution
+environments:
+
+
+.. toctree::
+
+ rexec.rst
+ bastion.rst
+
+.. seealso::
+
+ `Grail Home Page <http://grail.sourceforge.net/>`_
+ Grail, an Internet browser written in Python, uses these modules to support
+ Python applets. More information on the use of Python's restricted execution
+ mode in Grail is available on the Web site.
+