Ryan Hileman <lunixbo...@gmail.com> added the comment:
My understanding as per the outline in PEP 551 as well as PEP 578, is that the
audit system is meant primarily to observe the behavior of code rather than to
have good sandbox coverage / directly prevent behavior.
I am using audit hooks to observe the behavior of third party Python, and I
identified an indicator of shady behavior which includes code and frame object
access (which includes sys._getframe(), and __code__, both of which are part of
the original PEP 578).
I looked into it further and realized the CPython's auditing for those
attributes/objects is superficial. I understand that auditing isn't perfect,
and I'm not trying to change that. This patch just seems to me like a really
basic and obvious extension of the existing __code__ and getframe audit points.
----
I ask that if your main hesitation is the impact of future audit hooks, we use
this opportunity to establish a basic written precedent we can reference in the
future about which kind of audit hook modifications are likely to be accepted
without, say, another PEP.
One possible set of criteria:
- The added hooks should be justified as functionally identical to something
the existing PEP(s) suggested.
- Performance should be measured and it should have very little impact on
stdlib or general code.
- The requester should be expected to justify the change, e.g. how it closes
an obvious gap in an existing PEP 578 hook.
And my answers for those criteria:
- These are functionally equivalent to the existing PEP 578 hooks for
sys._getframe() and function.__code__ - they operate on similar types of
objects and are used for accessing the exact same information.
- Performance impact here appears to be only for debugging code, and
performance impact on debugging code is infinitesimal when no audit hook is
active.
- I am auditing code for trivial usage of Python frames and code objects, and
I can't do that sufficiently with the existing hooks (especially so now that
I'm publicly documenting this gap).
----
If the primary complaint is maintenance burden, would it be preferable to add
an attribute audit flag to PyMemberDef instead of using one-off PyGetSetDef
functions? e.g.:
static PyMemberDef frame_memberlist[] = {
{"f_code", T_OBJECT, OFF(f_code),
READONLY|AUDIT_ACCESS},
}
That would definitely simplify the implementation.
If these additions aren't worth it, I would almost recommend removing or
deprecating the existing __code__ and sys._getframe() audit hooks instead, as I
find them to be not very useful without this patch.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue42800>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
