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

Steve Dower steve.dower at python.org
Mon Apr 1 12:31:36 EDT 2019

On 31Mar2019 0538, Christian Heimes wrote:
> I don't like the fact that the PEP requires users to learn and use an
> additional layer to handle native code. Although we cannot provide a
> fully secure hook for native code, we could at least try to provide a
> best effort hook and document the limitations. A bit more information
> would make the verified open function more useful, too.

So instead they need to learn a significantly more complicated API? :) 
(I was very happy to be able to say "it's the same as open(p, 'rb')").

> PyObject *PyImport_OpenForExecution(
>      const char *path,
>      const char *intent,
>      int flags,
>      PyObject *context
> )
> - Path is an absolute (!) file path. The PEP doesn't specify if the file
> name is relative or absolute. IMO it should be always absolute.

Yeah, this is fair enough. I'll add it as a requirement.

> - The new intent argument lets the caller pass information how it
> intents to use the file, e.g. pythoncode, zipimport, nativecode (for
> loading a shared library/DLL), ctypes, ... This allows the verify hook
> to react on the intent and provide different verifications for e.g.
> Python code and native modules.

I had an intent argument at one point and the feedback I got (from teams 
who wanted to implement it) is that they wouldn't trust it anyway :)

In each case there should be associated audit events for tracking the 
intent (and interrupting at that point if it doesn't like the intended 
action), but for the simple case of "let me open this specific file" it 
doesn't really add much. And it almost certainly shouldn't impact 
decision making.

> - The flags argument is for additional flags, e.g. return an opened file
> or None, open the file in text or binary mode, ...

This just makes it harder for the hook implementer - now you have to 
allow encoding/errors arguments and probably more. And as mentioned 
above, there should be an audit event showing the intent before this 
call, and a hook can reject it at that point (rather than verify without 
actually returning the verified content).

> - Context is an optional Python object from the caller's context. For
> the import system, it could be the loader instance.

I think the audit event covers this, unless you have some way of using 
this context in mind that I can't think of?


More information about the Python-Dev mailing list