PEP 578: Add clarifications around open_code() for non-code files (#985)
This commit is contained in:
parent
d6a43fb3f9
commit
c633c2be56
27
pep-0578.rst
27
pep-0578.rst
|
@ -183,10 +183,10 @@ Most operating systems have a mechanism to distinguish between files
|
||||||
that can be executed and those that can not. For example, this may be an
|
that can be executed and those that can not. For example, this may be an
|
||||||
execute bit in the permissions field, a verified hash of the file
|
execute bit in the permissions field, a verified hash of the file
|
||||||
contents to detect potential code tampering, or file system path
|
contents to detect potential code tampering, or file system path
|
||||||
restrictions. These are an important security mechanism for preventing
|
restrictions. These are an important security mechanism for ensuring
|
||||||
execution of data or code that is not approved for a given environment.
|
that only code that has been approved for a given environment is
|
||||||
Currently, Python has no way to integrate with these when launching
|
executed. Currently, Python has no way to integrate with operating
|
||||||
scripts or importing modules.
|
system support when launching scripts or importing modules.
|
||||||
|
|
||||||
The new public C API for the verified open hook is::
|
The new public C API for the verified open hook is::
|
||||||
|
|
||||||
|
@ -238,6 +238,25 @@ Python, most imported code will go through both ``open_code()`` and the
|
||||||
log hook for ``compile``, and so care should be taken to avoid
|
log hook for ``compile``, and so care should be taken to avoid
|
||||||
repeating verification steps.
|
repeating verification steps.
|
||||||
|
|
||||||
|
File accesses that are not intentionally planning to execute code are
|
||||||
|
not expected to use this function. This includes loading pickles, XML
|
||||||
|
or YAML files, where code execution is generally considered malicious
|
||||||
|
rather than intentional. These operations should provide their own
|
||||||
|
auditing events, preferably distinguishing between normal functionality
|
||||||
|
(for example, ``Unpickler.load``) and code execution
|
||||||
|
(``Unpickler.find_class``).
|
||||||
|
|
||||||
|
A few examples: if the file type normally requires an execute bit (on
|
||||||
|
POSIX) or would warn when marked as having been downloaded from the
|
||||||
|
internet (on Windows), it should probably use ``open_code()`` rather
|
||||||
|
than plain ``open()``. Opening ZIP files using the ``ZipFile`` class
|
||||||
|
should use ``open()``, while opening them via ``zipimport`` should use
|
||||||
|
``open_code()`` to signal the correct intent. Code that uses the wrong
|
||||||
|
function for a particular context may bypass the hook, which in CPython
|
||||||
|
and the standard library should be considered a bug. Using a combination
|
||||||
|
of ``open_code`` hooks and auditing hooks is necessary to trace all
|
||||||
|
executed sources in the presence of arbitrary code.
|
||||||
|
|
||||||
There is no Python API provided for changing the open hook. To modify
|
There is no Python API provided for changing the open hook. To modify
|
||||||
import behavior from Python code, use the existing functionality
|
import behavior from Python code, use the existing functionality
|
||||||
provided by ``importlib``.
|
provided by ``importlib``.
|
||||||
|
|
Loading…
Reference in New Issue