[Bug #729817] Document the rexec and Bastion modules as dead
This commit is contained in:
parent
032bd0a9a8
commit
eabd9a1314
|
@ -4,7 +4,12 @@
|
|||
\declaremodule{standard}{Bastion}
|
||||
\modulesynopsis{Providing restricted access to objects.}
|
||||
\moduleauthor{Barry Warsaw}{bwarsaw@python.org}
|
||||
\versionchanged[Disabled module]{2.3}
|
||||
|
||||
\begin{notice}[warning]
|
||||
The documentation has been left in place to help in reading old code
|
||||
that uses the module.
|
||||
\end{notice}
|
||||
|
||||
% I'm concerned that the word 'bastion' won't be understood by people
|
||||
% for whom English is a second language, making the module name
|
||||
|
|
|
@ -1,22 +1,14 @@
|
|||
\chapter{Restricted Execution \label{restricted}}
|
||||
|
||||
In general, Python programs have complete access to the underlying
|
||||
operating system throug the various functions and classes, For
|
||||
example, a Python program can open any file for reading and writing by
|
||||
using the \function{open()} built-in function (provided the underlying
|
||||
operating system gives you permission!). This is exactly what you want
|
||||
for most applications.
|
||||
|
||||
There exists a class of applications for which this ``openness'' is
|
||||
inappropriate. Take Grail: a Web browser that accepts ``applets,''
|
||||
snippets of Python code, from anywhere on the Internet for execution
|
||||
on the local system. This can be used to improve the user interface
|
||||
of forms, for instance. Since the originator of the code is unknown,
|
||||
it is obvious that it cannot be trusted with the full resources of the
|
||||
local machine.
|
||||
\begin{notice}[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
|
||||
\module{rexec} and \module{Bastion} modules.
|
||||
\end{notice}
|
||||
|
||||
\emph{Restricted execution} is the basic framework in Python that allows
|
||||
for the segregation of trusted and untrusted code. It is based on the
|
||||
for the segregation of trusted and untrusted code. The framework is based on the
|
||||
notion that trusted Python code (a \emph{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
|
||||
|
@ -66,10 +58,6 @@ environments:
|
|||
\localmoduletable
|
||||
|
||||
\begin{seealso}
|
||||
\seetitle[http://www.python.org/doc/howto/rexec/]
|
||||
{Restricted Execution HOWTO}
|
||||
{Andrew Kuchling's tutorial on the use of the restricted
|
||||
execution facilities in Python.}
|
||||
\seetitle[http://grail.sourceforge.net/]{Grail Home Page}
|
||||
{Grail, an Internet browser written in Python, uses these
|
||||
modules to support Python applets. More
|
||||
|
|
|
@ -3,7 +3,12 @@
|
|||
|
||||
\declaremodule{standard}{rexec}
|
||||
\modulesynopsis{Basic restricted execution framework.}
|
||||
\versionchanged[Disabled module]{2.3}
|
||||
|
||||
\begin{notice}[warning]
|
||||
The documentation has been left in place to help in reading old code
|
||||
that uses the module.
|
||||
\end{notice}
|
||||
|
||||
This module contains the \class{RExec} class, which supports
|
||||
\method{r_eval()}, \method{r_execfile()}, \method{r_exec()}, and
|
||||
|
|
Loading…
Reference in New Issue