iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

PEP 578: Add clarifications around open_code() for non-code files (#985)

This commit is contained in:
Steve Dower 2019-04-10 11:46:20 -07:00 committed by GitHub
parent d6a43fb3f9
commit c633c2be56
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 23 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
pep-0578.rst
View File

@ -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
execute bit in the permissions field, a verified hash of the file
contents to detect potential code tampering, or file system path
restrictions. These are an important security mechanism for preventing
execution of data or code that is not approved for a given environment.
Currently, Python has no way to integrate with these when launching
scripts or importing modules.
restrictions. These are an important security mechanism for ensuring
that only code that has been approved for a given environment is
executed. Currently, Python has no way to integrate with operating
system support when launching scripts or importing modules.
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
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
import behavior from Python code, use the existing functionality
provided by ``importlib``.