[Python-Dev] PEP 578: Python Runtime Audit Hooks (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Sat Mar 30 10:47:32 EDT 2019

On Sat, 30 Mar 2019 at 06:14, Steve Dower <steve.dower at python.org> wrote:

On 29Mar2019 1218, Christian Heimes wrote: > On 28/03/2019 23.35, Steve Dower wrote: >> 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. > > I think that the import hook needs to be extended. It only works for > simple Python files or pyc files. There are at least two other important > scenarios: zipimport and shared libraries. > > For example how does the importhook work in regarding of alternative > importers like zipimport? What does the import hook 'see' for an import > from a zipfile?

Yes, good point. I think opening the zip file with openforimport() is the right place to do it, as this operation relates to opening the file on disk rather than files within it.

I like this PEP in principle, but the specific "open_for_import" name bothers me a lot, as it implies that "importing" is the only situation where a file will be opened for code execution. Accordingly, I think proceeding with that name will increase the risk of unintentional audit bypasses, as folks (both within the core development team and outside it) use the regular open function for data that they then pass to exec(), or for some other purpose that nevertheless allows arbitrary code execution (e.g. the shelve module loading pickle files from disk).

If this part of the API were lower down the stack (e.g. "_io.open_for_code_execution") then I think it would make more sense - APIs like tokenize.open(), runpy.run_path(), PyRun_SimpleFile(), shelve, etc, could use that, without having to introduce a dependency on importlib to get access to the functionality.

Cheers, Nick.

-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia

More information about the Python-Dev mailing list