[Python-Dev] PEP 578: Python Runtime Audit Hooks
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
> - 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