Deprecated since version 2.6: The rexec module has been removed in Python 3.0.
Changed in version 2.3: Disabled module.
Warning
The documentation has been left in place to help in reading old code that uses the module.
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.
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, 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.
See also
RExec instances support the following methods:
Methods whose names begin with s_ are similar to the functions beginning with r_, but the code will be granted access to restricted versions of the standard I/O streams sys.stdin, sys.stderr, and sys.stdout.
RExec objects must also support various methods which will be implicitly called by code executing in the restricted environment. Overriding these methods in a subclass is used to change the policies enforced by a restricted environment.
And their equivalents with access to restricted standard I/O streams:
The RExec class has the following class attributes, which are used by the __init__() method. Changing them on an existing instance won’t have any effect; instead, create a subclass of RExec and assign them new values in the class definition. Instances of the new class will then use those new values. All these attributes are tuples of strings.
Let us say that we want a slightly more relaxed policy than the standard RExec class. For example, if we’re willing to allow files in /tmp to be written, we can subclass the RExec class:
class TmpWriterRExec(rexec.RExec):
def r_open(self, file, mode='r', buf=-1):
if mode in ('r', 'rb'):
pass
elif mode in ('w', 'wb', 'a', 'ab'):
# check filename : must begin with /tmp/
if file[:5]!='/tmp/':
raise IOError, "can't write outside /tmp"
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)
Notice that the above code will occasionally forbid a perfectly valid filename; for example, code in the restricted environment won’t be able to open a file called /tmp/foo/../bar. To fix this, the r_open() method would have to simplify the filename to /tmp/bar, which would require splitting apart the filename and performing various operations on it. In cases where security is at stake, it may be preferable to write simple code which is sometimes overly restrictive, instead of more general code that is also more complex and may harbor a subtle security hole.