[Python-Dev] PEP 578: Python Runtime Audit Hooks

[Nick Coghlan]

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 open_for_import() 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