mirrors/cpython
1
0
Fork 0
mirror of https://github.com/python/cpython.git synced 2025-07-25 12:14:38 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 8

Done with this for 1.4.

Browse source
This commit is contained in:
Guido van Rossum 1996-10-24 22:14:06 +00:00
parent 3a26dd88af
commit f73f79b5fd
4 changed files with 192 additions and 132 deletions
Download patch file Download diff file Expand all files Collapse all files

50
Doc/lib/librestricted.tex
View file

@ -1,34 +1,35 @@
\chapter{Restricted Execution} \chapter{Restricted Execution}
In general, executing Python programs have complete access to the In general, Python programs have complete access to the underlying
underlying operating system through the various functions and classes operating system throug the various functions and classes, For
contained in Python's modules. For example, a Python program can open example, a Python program can open any file for reading and writing by
any file\footnote{Provided the underlying OS gives you permission!} using the \code{open()} built-in function (provided the underlying OS
for reading and writing by using the gives you permission!). This is exactly what you want for most
\code{open()} built-in function. This is exactly what you want for applications.
most applications.
There is a class of applications for which this ``openness'' is There exists a class of applications for which this ``openness'' is
inappropriate. Imagine a web browser that accepts ``applets'', snippets of inappropriate. Take Grail: a web browser that accepts ``applets'',
Python code, from anywhere on the Internet for execution on the local snippets of Python code, from anywhere on the Internet for execution
system. Since the originator of the code is unknown, it is obvious that it on the local system. This can be used to improve the user interface
cannot be trusted with the full resources of the local machine. 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.
\emph{Restricted execution} is the basic Python framework that allows \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. It is based on the
notion that trusted Python code (a \emph{supervisor}) can create a notion that trusted Python code (a \emph{supervisor}) can create a
``padded cell' (or environment) of limited permissions, and run the ``padded cell' (or environment) with limited permissions, and run the
untrusted code within this cell. The untrusted code cannot break out untrusted code within this cell. The untrusted code cannot break out
of its cell, and can only interact with sensitive system resources of its cell, and can only interact with sensitive system resources
through interfaces defined, and managed by the trusted code. The term through interfaces defined and managed by the trusted code. The term
``restricted execution'' is favored over the term ``safe-Python'' ``restricted execution'' is favored over ``safe-Python''
since true safety is hard to define, and is determined by the way the since true safety is hard to define, and is determined by the way the
restricted environment is created. Note that the restricted restricted environment is created. Note that the restricted
environments can be nested, with inner cells creating subcells of environments can be nested, with inner cells creating subcells of
lesser, but never greater, privledge. lesser, but never greater, privilege.
An interesting aspect of Python's restricted execution model is that An interesting aspect of Python's restricted execution model is that
the attributes presented to untrusted code usually have the same names the interfaces presented to untrusted code usually have the same names
as those presented to trusted code. Therefore no special interfaces as those presented to trusted code. Therefore no special interfaces
need to be learned to write code designed to run in a restricted need to be learned to write code designed to run in a restricted
environment. And because the exact nature of the padded cell is environment. And because the exact nature of the padded cell is
@ -42,11 +43,22 @@ may redefine the built-in
\code{chroot()}-like operation on the \var{filename} parameter, such \code{chroot()}-like operation on the \var{filename} parameter, such
that root is always relative to some safe ``sandbox'' area of the that root is always relative to some safe ``sandbox'' area of the
filesystem. In this case, the untrusted code would still see an filesystem. In this case, the untrusted code would still see an
\code{open()} function in its \code{__builtin__} module, with the same built-in \code{open()} function in its environment, with the same
calling interface. The semantics would be identical too, with calling interface. The semantics would be identical too, with
\code{IOError}s being raised when the supervisor determined that an \code{IOError}s being raised when the supervisor determined that an
unallowable parameter is being used. 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
\code{__builtins__} object in its global variables: if this is (the
dictionary of) the standard \code{__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 \code{func_globals} and the
class and instance object attribute \code{__dict__} are unavailable.
Two modules provide the framework for setting up restricted execution Two modules provide the framework for setting up restricted execution
environments: environments:

112
Doc/lib/librexec.tex
View file

@ -6,7 +6,8 @@ This module contains the \code{RExec} class, which supports
\code{r_exec()}, \code{r_eval()}, \code{r_execfile()}, and \code{r_exec()}, \code{r_eval()}, \code{r_execfile()}, and
\code{r_import()} methods, which are restricted versions of the standard \code{r_import()} methods, which are restricted versions of the standard
Python functions \code{exec()}, \code{eval()}, \code{execfile()}, and Python functions \code{exec()}, \code{eval()}, \code{execfile()}, and
\code{import()}. Code executed in this restricted environment will the \code{import} statement.
Code executed in this restricted environment will
only have access to modules and functions that are deemed safe; you only have access to modules and functions that are deemed safe; you
can subclass \code{RExec} to add or remove capabilities as desired. can subclass \code{RExec} to add or remove capabilities as desired.
@ -14,14 +15,13 @@ can subclass \code{RExec} to add or remove capabilities as desired.
unsafe operations like reading or writing disk files, or using TCP/IP unsafe operations like reading or writing disk files, or using TCP/IP
sockets. However, it does not protect against code using extremely sockets. However, it does not protect against code using extremely
large amounts of memory or CPU time. large amounts of memory or CPU time.
% XXX is there any protection against this?
\begin{funcdesc}{RExec}{\optional{hooks\, verbose} } \begin{funcdesc}{RExec}{\optional{hooks\optional{\, verbose}}}
Returns an instance of the \code{RExec} class. Returns an instance of the \code{RExec} class.
% XXX is ihooks.py documented? If yes, there should be a ref here
\var{hooks} is an instance of the \code{RHooks} class or a subclass of it. \var{hooks} is an instance of the \code{RHooks} class or a subclass of it.
If it is omitted or \code{None}, the default \code{RHooks} class is
instantiated.
Whenever the RExec module searches for a module (even a built-in one) 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 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 system itself. Rather, it calls methods of an RHooks instance that
@ -30,7 +30,7 @@ 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 object that's part of the RExec object. This allows another level of
flexibility, e.g. using packages.) flexibility, e.g. using packages.)
By providing an alternate RHooks object, we can control the actual By providing an alternate RHooks object, we can control the
file system accesses made to import a module, without changing the file system accesses made to import a module, without changing the
actual algorithm that controls the order in which those accesses are actual algorithm that controls the order in which those accesses are
made. For instance, we could substitute an RHooks object that passes made. For instance, we could substitute an RHooks object that passes
@ -38,12 +38,11 @@ all filesystem requests to a file server elsewhere, via some RPC
mechanism such as ILU. Grail's applet loader uses this to support mechanism such as ILU. Grail's applet loader uses this to support
importing applets from a URL for a directory. importing applets from a URL for a directory.
% XXX does verbose actually do anything at the moment? If \var{verbose} is true, additional debugging output may be sent to
If \var{verbose} is true, additional debugging output will be sent to
standard output. standard output.
\end{funcdesc} \end{funcdesc}
RExec instances have the following attributes, which are used by the The RExec class has the following class attributes, which are used by the
\code{__init__} method. Changing them on an existing instance won't \code{__init__} method. Changing them on an existing instance won't
have any effect; instead, create a subclass of \code{RExec} and assign have any effect; instead, create a subclass of \code{RExec} and assign
them new values in the class definition. Instances of the new class them new values in the class definition. Instances of the new class
@ -53,23 +52,32 @@ strings.
\renewcommand{\indexsubitem}{(RExec object attribute)} \renewcommand{\indexsubitem}{(RExec object attribute)}
\begin{datadesc}{nok_builtin_names} \begin{datadesc}{nok_builtin_names}
Contains the names of built-in functions which will \emph{not} be Contains the names of built-in functions which will \emph{not} be
available to programs running in the restricted environment. The available to programs running in the restricted environment. The
value for \code{RExec} is \code{('open',} \code{reload',} value for \code{RExec} is \code{('open',} \code{'reload',}
\code{__import__')}. \code{'__import__')}. (This gives the exceptions, because by far the
majority of built-in functions are harmless. A subclass that wants to
override this variable should probably start with the value from the
base class and concatenate additional forbidden functions --- when new
dangerous built-in functions are added to Python, they will also be
added to this module.)
\end{datadesc} \end{datadesc}
\begin{datadesc}{ok_builtin_modules} \begin{datadesc}{ok_builtin_modules}
Contains the names of built-in modules which can be safely imported. Contains the names of built-in modules which can be safely imported.
The value for \code{RExec} is \code{('array',} \code{'binascii',} \code{'audioop',} The value for \code{RExec} is \code{('audioop',} \code{'array',}
\code{'imageop',} \code{'marshal',} \code{'math',} \code{'md5',} \code{'parser',} \code{'regex',} \code{'rotor',} \code{'binascii',} \code{'cmath',} \code{'errno',} \code{'imageop',}
\code{'select',} \code{'strop',} \code{'struct',} \code{'time')}. \code{'marshal',} \code{'math',} \code{'md5',} \code{'operator',}
\code{'parser',} \code{'regex',} \code{'rotor',} \code{'select',}
\code{'strop',} \code{'struct',} \code{'time')}. A similar remark
about overriding this variable applies --- use the value from the base
class as a starting point.
\end{datadesc} \end{datadesc}
\begin{datadesc}{ok_path} \begin{datadesc}{ok_path}
Contains the directories which will be searched when an \code{import} Contains the directories which will be searched when an \code{import}
is performed in the restricted environment. is performed in the restricted environment.
The value for \code{RExec} is the same as \code{sys.path} for The value for \code{RExec} is the same as \code{sys.path} (at the time
unrestricted code. the module is loaded) for unrestricted code.
\end{datadesc} \end{datadesc}
\begin{datadesc}{ok_posix_names} \begin{datadesc}{ok_posix_names}
@ -84,35 +92,38 @@ value for \code{RExec} is \code{('error',} \code{'fstat',}
\end{datadesc} \end{datadesc}
\begin{datadesc}{ok_sys_names} \begin{datadesc}{ok_sys_names}
Contains the names of the functions and variables in the \code{sys} module which will be Contains the names of the functions and variables in the \code{sys}
available to programs running in the restricted environment. The module which will be available to programs running in the restricted
value for \code{RExec} is \code{('ps1',} \code{'ps2',} environment. The value for \code{RExec} is \code{('ps1',}
\code{'copyright',} \code{'version',} \code{'platform',} \code{'exit',} \code{'ps2',} \code{'copyright',} \code{'version',} \code{'platform',}
\code{'maxint')}. \code{'exit',} \code{'maxint')}.
\end{datadesc} \end{datadesc}
RExec instances support the following methods: RExec instances support the following methods:
\renewcommand{\indexsubitem}{(RExec object method)} \renewcommand{\indexsubitem}{(RExec object method)}
\begin{funcdesc}{r_eval}{code} \begin{funcdesc}{r_eval}{code}
\var{code} must either be a string containing a Python expression, or a compiled code object, which will \var{code} must either be a string containing a Python expression, or
be evaluated in the restricted environment. The value of the expression or code object will be returned. a compiled code object, which will be evaluated in the restricted
environment's \code{__main__} module. The value of the expression or
code object will be returned.
\end{funcdesc} \end{funcdesc}
\begin{funcdesc}{r_exec}{code} \begin{funcdesc}{r_exec}{code}
\var{code} must either be a string containing one or more lines of Python code, or a compiled code object, \var{code} must either be a string containing one or more lines of
which will be executed in the restricted environment. Python code, or a compiled code object, which will be executed in the
restricted environment's \code{__main__} module.
\end{funcdesc} \end{funcdesc}
\begin{funcdesc}{r_execfile}{filename} \begin{funcdesc}{r_execfile}{filename}
Execute the Python code contained in the file \var{filename} in the Execute the Python code contained in the file \var{filename} in the
restricted environment. restricted environment's \code{__main__} module.
\end{funcdesc} \end{funcdesc}
Methods whose names begin with \code{s_} are similar to the functions Methods whose names begin with \code{s_} are similar to the functions
beginning with \code{r_}, but the code will be granted access to beginning with \code{r_}, but the code will be granted access to
restricted versions of \code{sys.stdin}, \code{sys.stderr}, and restricted versions of the standard I/O streans \code{sys.stdin},
\code{sys.stdout}. \code{sys.stderr}, and \code{sys.stdout}.
\begin{funcdesc}{s_eval}{code} \begin{funcdesc}{s_eval}{code}
\var{code} must be a string containing a Python expression, which will \var{code} must be a string containing a Python expression, which will
@ -129,13 +140,14 @@ Execute the Python code contained in the file \var{filename} in the
restricted environment. restricted environment.
\end{funcdesc} \end{funcdesc}
\code{RExec} objects must also support various methods which will be implicitly called \code{RExec} objects must also support various methods which will be
by code executing in the restricted environment. Overriding these implicitly called by code executing in the restricted environment.
methods in a subclass is used to change the policies enforced by a restricted environment. Overriding these methods in a subclass is used to change the policies
enforced by a restricted environment.
\begin{funcdesc}{r_import}{modulename\optional{\, globals, locals, fromlist}} \begin{funcdesc}{r_import}{modulename\optional{\, globals\, locals\, fromlist}}
Import the module \var{modulename}, raising an \code{ImportError} exception Import the module \var{modulename}, raising an \code{ImportError}
if the module is considered unsafe. exception if the module is considered unsafe.
\end{funcdesc} \end{funcdesc}
\begin{funcdesc}{r_open}{filename\optional{\, mode\optional{\, bufsize}}} \begin{funcdesc}{r_open}{filename\optional{\, mode\optional{\, bufsize}}}
@ -144,7 +156,8 @@ environment. The arguments are identical to those of \code{open()},
and a file object (or a class instance compatible with file objects) and a file object (or a class instance compatible with file objects)
should be returned. \code{RExec}'s default behaviour is allow opening should be returned. \code{RExec}'s default behaviour is allow opening
any file for reading, but forbidding any attempt to write a file. See any file for reading, but forbidding any attempt to write a file. See
the example below for an implementation of a less restrictive \code{r_open()}. the example below for an implementation of a less restrictive
\code{r_open()}.
\end{funcdesc} \end{funcdesc}
\begin{funcdesc}{r_reload}{module} \begin{funcdesc}{r_reload}{module}
@ -152,13 +165,15 @@ Reload the module object \var{module}, re-parsing and re-initializing it.
\end{funcdesc} \end{funcdesc}
\begin{funcdesc}{r_unload}{module} \begin{funcdesc}{r_unload}{module}
Unload the module object \var{module}. Unload the module object \var{module} (i.e., remove it from the
% XXX what are the semantics of this? restricted environment's \code{sys.modules} dictionary).
\end{funcdesc} \end{funcdesc}
And their equivalents with access to restricted standard I/O streams:
\begin{funcdesc}{s_import}{modulename\optional{\, globals, locals, fromlist}} \begin{funcdesc}{s_import}{modulename\optional{\, globals, locals, fromlist}}
Import the module \var{modulename}, raising an \code{ImportError} exception Import the module \var{modulename}, raising an \code{ImportError}
if the module is considered unsafe. exception if the module is considered unsafe.
\end{funcdesc} \end{funcdesc}
\begin{funcdesc}{s_reload}{module} \begin{funcdesc}{s_reload}{module}
@ -179,13 +194,16 @@ standard RExec class. For example, if we're willing to allow files in
\bcode\begin{verbatim} \bcode\begin{verbatim}
class TmpWriterRExec(rexec.RExec): class TmpWriterRExec(rexec.RExec):
def r_open(self, file, mode='r', buf=-1): def r_open(self, file, mode='r', buf=-1):
if mode in ('r', 'rb'): pass if mode in ('r', 'rb'):
elif mode in ('w', 'wb'): pass
# check filename : must begin with /tmp/ elif mode in ('w', 'wb', 'a', 'ab'):
if file[0:5]!='/tmp/': # check filename : must begin with /tmp/
raise IOError, "can't open files for writing outside of /tmp" if file[:5]!='/tmp/':
elif string.find(file, '/../')!=-1: raise IOError, "can't write outside /tmp"
raise IOError, "'..' in filename; open for writing forbidden" elif (string.find(file, '/../') >= 0 or
file[:3] == '../' or file[-3:] == '/..'):
raise IOError, "'..' in filename forbidden"
else: raise IOError, "Illegal open() mode"
return open(file, mode, buf) return open(file, mode, buf)
\end{verbatim}\ecode \end{verbatim}\ecode

50
Doc/librestricted.tex
View file

@ -1,34 +1,35 @@
\chapter{Restricted Execution} \chapter{Restricted Execution}
In general, executing Python programs have complete access to the In general, Python programs have complete access to the underlying
underlying operating system through the various functions and classes operating system throug the various functions and classes, For
contained in Python's modules. For example, a Python program can open example, a Python program can open any file for reading and writing by
any file\footnote{Provided the underlying OS gives you permission!} using the \code{open()} built-in function (provided the underlying OS
for reading and writing by using the gives you permission!). This is exactly what you want for most
\code{open()} built-in function. This is exactly what you want for applications.
most applications.
There is a class of applications for which this ``openness'' is There exists a class of applications for which this ``openness'' is
inappropriate. Imagine a web browser that accepts ``applets'', snippets of inappropriate. Take Grail: a web browser that accepts ``applets'',
Python code, from anywhere on the Internet for execution on the local snippets of Python code, from anywhere on the Internet for execution
system. Since the originator of the code is unknown, it is obvious that it on the local system. This can be used to improve the user interface
cannot be trusted with the full resources of the local machine. 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.
\emph{Restricted execution} is the basic Python framework that allows \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. It is based on the
notion that trusted Python code (a \emph{supervisor}) can create a notion that trusted Python code (a \emph{supervisor}) can create a
``padded cell' (or environment) of limited permissions, and run the ``padded cell' (or environment) with limited permissions, and run the
untrusted code within this cell. The untrusted code cannot break out untrusted code within this cell. The untrusted code cannot break out
of its cell, and can only interact with sensitive system resources of its cell, and can only interact with sensitive system resources
through interfaces defined, and managed by the trusted code. The term through interfaces defined and managed by the trusted code. The term
``restricted execution'' is favored over the term ``safe-Python'' ``restricted execution'' is favored over ``safe-Python''
since true safety is hard to define, and is determined by the way the since true safety is hard to define, and is determined by the way the
restricted environment is created. Note that the restricted restricted environment is created. Note that the restricted
environments can be nested, with inner cells creating subcells of environments can be nested, with inner cells creating subcells of
lesser, but never greater, privledge. lesser, but never greater, privilege.
An interesting aspect of Python's restricted execution model is that An interesting aspect of Python's restricted execution model is that
the attributes presented to untrusted code usually have the same names the interfaces presented to untrusted code usually have the same names
as those presented to trusted code. Therefore no special interfaces as those presented to trusted code. Therefore no special interfaces
need to be learned to write code designed to run in a restricted need to be learned to write code designed to run in a restricted
environment. And because the exact nature of the padded cell is environment. And because the exact nature of the padded cell is
@ -42,11 +43,22 @@ may redefine the built-in
\code{chroot()}-like operation on the \var{filename} parameter, such \code{chroot()}-like operation on the \var{filename} parameter, such
that root is always relative to some safe ``sandbox'' area of the that root is always relative to some safe ``sandbox'' area of the
filesystem. In this case, the untrusted code would still see an filesystem. In this case, the untrusted code would still see an
\code{open()} function in its \code{__builtin__} module, with the same built-in \code{open()} function in its environment, with the same
calling interface. The semantics would be identical too, with calling interface. The semantics would be identical too, with
\code{IOError}s being raised when the supervisor determined that an \code{IOError}s being raised when the supervisor determined that an
unallowable parameter is being used. 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
\code{__builtins__} object in its global variables: if this is (the
dictionary of) the standard \code{__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 \code{func_globals} and the
class and instance object attribute \code{__dict__} are unavailable.
Two modules provide the framework for setting up restricted execution Two modules provide the framework for setting up restricted execution
environments: environments:

112
Doc/librexec.tex
View file

@ -6,7 +6,8 @@ This module contains the \code{RExec} class, which supports
\code{r_exec()}, \code{r_eval()}, \code{r_execfile()}, and \code{r_exec()}, \code{r_eval()}, \code{r_execfile()}, and
\code{r_import()} methods, which are restricted versions of the standard \code{r_import()} methods, which are restricted versions of the standard
Python functions \code{exec()}, \code{eval()}, \code{execfile()}, and Python functions \code{exec()}, \code{eval()}, \code{execfile()}, and
\code{import()}. Code executed in this restricted environment will the \code{import} statement.
Code executed in this restricted environment will
only have access to modules and functions that are deemed safe; you only have access to modules and functions that are deemed safe; you
can subclass \code{RExec} to add or remove capabilities as desired. can subclass \code{RExec} to add or remove capabilities as desired.
@ -14,14 +15,13 @@ can subclass \code{RExec} to add or remove capabilities as desired.
unsafe operations like reading or writing disk files, or using TCP/IP unsafe operations like reading or writing disk files, or using TCP/IP
sockets. However, it does not protect against code using extremely sockets. However, it does not protect against code using extremely
large amounts of memory or CPU time. large amounts of memory or CPU time.
% XXX is there any protection against this?
\begin{funcdesc}{RExec}{\optional{hooks\, verbose} } \begin{funcdesc}{RExec}{\optional{hooks\optional{\, verbose}}}
Returns an instance of the \code{RExec} class. Returns an instance of the \code{RExec} class.
% XXX is ihooks.py documented? If yes, there should be a ref here
\var{hooks} is an instance of the \code{RHooks} class or a subclass of it. \var{hooks} is an instance of the \code{RHooks} class or a subclass of it.
If it is omitted or \code{None}, the default \code{RHooks} class is
instantiated.
Whenever the RExec module searches for a module (even a built-in one) 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 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 system itself. Rather, it calls methods of an RHooks instance that
@ -30,7 +30,7 @@ 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 object that's part of the RExec object. This allows another level of
flexibility, e.g. using packages.) flexibility, e.g. using packages.)
By providing an alternate RHooks object, we can control the actual By providing an alternate RHooks object, we can control the
file system accesses made to import a module, without changing the file system accesses made to import a module, without changing the
actual algorithm that controls the order in which those accesses are actual algorithm that controls the order in which those accesses are
made. For instance, we could substitute an RHooks object that passes made. For instance, we could substitute an RHooks object that passes
@ -38,12 +38,11 @@ all filesystem requests to a file server elsewhere, via some RPC
mechanism such as ILU. Grail's applet loader uses this to support mechanism such as ILU. Grail's applet loader uses this to support
importing applets from a URL for a directory. importing applets from a URL for a directory.
% XXX does verbose actually do anything at the moment? If \var{verbose} is true, additional debugging output may be sent to
If \var{verbose} is true, additional debugging output will be sent to
standard output. standard output.
\end{funcdesc} \end{funcdesc}
RExec instances have the following attributes, which are used by the The RExec class has the following class attributes, which are used by the
\code{__init__} method. Changing them on an existing instance won't \code{__init__} method. Changing them on an existing instance won't
have any effect; instead, create a subclass of \code{RExec} and assign have any effect; instead, create a subclass of \code{RExec} and assign
them new values in the class definition. Instances of the new class them new values in the class definition. Instances of the new class
@ -53,23 +52,32 @@ strings.
\renewcommand{\indexsubitem}{(RExec object attribute)} \renewcommand{\indexsubitem}{(RExec object attribute)}
\begin{datadesc}{nok_builtin_names} \begin{datadesc}{nok_builtin_names}
Contains the names of built-in functions which will \emph{not} be Contains the names of built-in functions which will \emph{not} be
available to programs running in the restricted environment. The available to programs running in the restricted environment. The
value for \code{RExec} is \code{('open',} \code{reload',} value for \code{RExec} is \code{('open',} \code{'reload',}
\code{__import__')}. \code{'__import__')}. (This gives the exceptions, because by far the
majority of built-in functions are harmless. A subclass that wants to
override this variable should probably start with the value from the
base class and concatenate additional forbidden functions --- when new
dangerous built-in functions are added to Python, they will also be
added to this module.)
\end{datadesc} \end{datadesc}
\begin{datadesc}{ok_builtin_modules} \begin{datadesc}{ok_builtin_modules}
Contains the names of built-in modules which can be safely imported. Contains the names of built-in modules which can be safely imported.
The value for \code{RExec} is \code{('array',} \code{'binascii',} \code{'audioop',} The value for \code{RExec} is \code{('audioop',} \code{'array',}
\code{'imageop',} \code{'marshal',} \code{'math',} \code{'md5',} \code{'parser',} \code{'regex',} \code{'rotor',} \code{'binascii',} \code{'cmath',} \code{'errno',} \code{'imageop',}
\code{'select',} \code{'strop',} \code{'struct',} \code{'time')}. \code{'marshal',} \code{'math',} \code{'md5',} \code{'operator',}
\code{'parser',} \code{'regex',} \code{'rotor',} \code{'select',}
\code{'strop',} \code{'struct',} \code{'time')}. A similar remark
about overriding this variable applies --- use the value from the base
class as a starting point.
\end{datadesc} \end{datadesc}
\begin{datadesc}{ok_path} \begin{datadesc}{ok_path}
Contains the directories which will be searched when an \code{import} Contains the directories which will be searched when an \code{import}
is performed in the restricted environment. is performed in the restricted environment.
The value for \code{RExec} is the same as \code{sys.path} for The value for \code{RExec} is the same as \code{sys.path} (at the time
unrestricted code. the module is loaded) for unrestricted code.
\end{datadesc} \end{datadesc}
\begin{datadesc}{ok_posix_names} \begin{datadesc}{ok_posix_names}
@ -84,35 +92,38 @@ value for \code{RExec} is \code{('error',} \code{'fstat',}
\end{datadesc} \end{datadesc}
\begin{datadesc}{ok_sys_names} \begin{datadesc}{ok_sys_names}
Contains the names of the functions and variables in the \code{sys} module which will be Contains the names of the functions and variables in the \code{sys}
available to programs running in the restricted environment. The module which will be available to programs running in the restricted
value for \code{RExec} is \code{('ps1',} \code{'ps2',} environment. The value for \code{RExec} is \code{('ps1',}
\code{'copyright',} \code{'version',} \code{'platform',} \code{'exit',} \code{'ps2',} \code{'copyright',} \code{'version',} \code{'platform',}
\code{'maxint')}. \code{'exit',} \code{'maxint')}.
\end{datadesc} \end{datadesc}
RExec instances support the following methods: RExec instances support the following methods:
\renewcommand{\indexsubitem}{(RExec object method)} \renewcommand{\indexsubitem}{(RExec object method)}
\begin{funcdesc}{r_eval}{code} \begin{funcdesc}{r_eval}{code}
\var{code} must either be a string containing a Python expression, or a compiled code object, which will \var{code} must either be a string containing a Python expression, or
be evaluated in the restricted environment. The value of the expression or code object will be returned. a compiled code object, which will be evaluated in the restricted
environment's \code{__main__} module. The value of the expression or
code object will be returned.
\end{funcdesc} \end{funcdesc}
\begin{funcdesc}{r_exec}{code} \begin{funcdesc}{r_exec}{code}
\var{code} must either be a string containing one or more lines of Python code, or a compiled code object, \var{code} must either be a string containing one or more lines of
which will be executed in the restricted environment. Python code, or a compiled code object, which will be executed in the
restricted environment's \code{__main__} module.
\end{funcdesc} \end{funcdesc}
\begin{funcdesc}{r_execfile}{filename} \begin{funcdesc}{r_execfile}{filename}
Execute the Python code contained in the file \var{filename} in the Execute the Python code contained in the file \var{filename} in the
restricted environment. restricted environment's \code{__main__} module.
\end{funcdesc} \end{funcdesc}
Methods whose names begin with \code{s_} are similar to the functions Methods whose names begin with \code{s_} are similar to the functions
beginning with \code{r_}, but the code will be granted access to beginning with \code{r_}, but the code will be granted access to
restricted versions of \code{sys.stdin}, \code{sys.stderr}, and restricted versions of the standard I/O streans \code{sys.stdin},
\code{sys.stdout}. \code{sys.stderr}, and \code{sys.stdout}.
\begin{funcdesc}{s_eval}{code} \begin{funcdesc}{s_eval}{code}
\var{code} must be a string containing a Python expression, which will \var{code} must be a string containing a Python expression, which will
@ -129,13 +140,14 @@ Execute the Python code contained in the file \var{filename} in the
restricted environment. restricted environment.
\end{funcdesc} \end{funcdesc}
\code{RExec} objects must also support various methods which will be implicitly called \code{RExec} objects must also support various methods which will be
by code executing in the restricted environment. Overriding these implicitly called by code executing in the restricted environment.
methods in a subclass is used to change the policies enforced by a restricted environment. Overriding these methods in a subclass is used to change the policies
enforced by a restricted environment.
\begin{funcdesc}{r_import}{modulename\optional{\, globals, locals, fromlist}} \begin{funcdesc}{r_import}{modulename\optional{\, globals\, locals\, fromlist}}
Import the module \var{modulename}, raising an \code{ImportError} exception Import the module \var{modulename}, raising an \code{ImportError}
if the module is considered unsafe. exception if the module is considered unsafe.
\end{funcdesc} \end{funcdesc}
\begin{funcdesc}{r_open}{filename\optional{\, mode\optional{\, bufsize}}} \begin{funcdesc}{r_open}{filename\optional{\, mode\optional{\, bufsize}}}
@ -144,7 +156,8 @@ environment. The arguments are identical to those of \code{open()},
and a file object (or a class instance compatible with file objects) and a file object (or a class instance compatible with file objects)
should be returned. \code{RExec}'s default behaviour is allow opening should be returned. \code{RExec}'s default behaviour is allow opening
any file for reading, but forbidding any attempt to write a file. See any file for reading, but forbidding any attempt to write a file. See
the example below for an implementation of a less restrictive \code{r_open()}. the example below for an implementation of a less restrictive
\code{r_open()}.
\end{funcdesc} \end{funcdesc}
\begin{funcdesc}{r_reload}{module} \begin{funcdesc}{r_reload}{module}
@ -152,13 +165,15 @@ Reload the module object \var{module}, re-parsing and re-initializing it.
\end{funcdesc} \end{funcdesc}
\begin{funcdesc}{r_unload}{module} \begin{funcdesc}{r_unload}{module}
Unload the module object \var{module}. Unload the module object \var{module} (i.e., remove it from the
% XXX what are the semantics of this? restricted environment's \code{sys.modules} dictionary).
\end{funcdesc} \end{funcdesc}
And their equivalents with access to restricted standard I/O streams:
\begin{funcdesc}{s_import}{modulename\optional{\, globals, locals, fromlist}} \begin{funcdesc}{s_import}{modulename\optional{\, globals, locals, fromlist}}
Import the module \var{modulename}, raising an \code{ImportError} exception Import the module \var{modulename}, raising an \code{ImportError}
if the module is considered unsafe. exception if the module is considered unsafe.
\end{funcdesc} \end{funcdesc}
\begin{funcdesc}{s_reload}{module} \begin{funcdesc}{s_reload}{module}
@ -179,13 +194,16 @@ standard RExec class. For example, if we're willing to allow files in
\bcode\begin{verbatim} \bcode\begin{verbatim}
class TmpWriterRExec(rexec.RExec): class TmpWriterRExec(rexec.RExec):
def r_open(self, file, mode='r', buf=-1): def r_open(self, file, mode='r', buf=-1):
if mode in ('r', 'rb'): pass if mode in ('r', 'rb'):
elif mode in ('w', 'wb'): pass
# check filename : must begin with /tmp/ elif mode in ('w', 'wb', 'a', 'ab'):
if file[0:5]!='/tmp/': # check filename : must begin with /tmp/
raise IOError, "can't open files for writing outside of /tmp" if file[:5]!='/tmp/':
elif string.find(file, '/../')!=-1: raise IOError, "can't write outside /tmp"
raise IOError, "'..' in filename; open for writing forbidden" elif (string.find(file, '/../') >= 0 or
file[:3] == '../' or file[-3:] == '/..'):
raise IOError, "'..' in filename forbidden"
else: raise IOError, "Illegal open() mode"
return open(file, mode, buf) return open(file, mode, buf)
\end{verbatim}\ecode \end{verbatim}\ecode