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?
Cheers,
Steve
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
