Missing audit hooks in several extension modules

[RobinJadoul]

Bug report

Bug description:

Several extension modules don't fully emit the relevant audit events, leading to file read or process spawning without any traceability.
In particular:

• Calling a _ctypes.CFuncPtr does not emit ctypes.call_function. When combined with some known addresses, this can result in arbitrary functions in libc or python getting called. Such addresses could come from id, ctypes.pythonapi._handle, passing a byref pointer to ctypes.cast, or probably still several other methods. Coincidentally, the ctypes.cast method would by audited by the same ctypes.call_function once it is present. The downside is that it may also result in multiple audit hooks for functions like ctypes.string_at that have their own specialized audit hook event too.
• Related, and maybe debatable, but constructing a _ctypes.CFuncPtr might fall under the audit event ctypes.cdata, as it is in spirit (though not in implementation) similar to calling a .from_address. An option might be to introduce ctypes.cdata/function similar to ctypes.cdata/buffer for this.
• The readline module can open and read a file through readline.read_history_file without having an open audit hook. Together with readline.get_history_item, this can lead to unaudited file reads. A similar situation exists for some other functions in this library.
• The _posixsubprocess.fork_exec function, and its only user in the standard library, multiprocessing.util.spawnv_passfds perform a fork + exec without any audit hooks. One would expect either os.fork and os.exec or the functionally similar os.posix_spawn here.

I'm happy to make a quick PR for these and adjust any specific event types to be more consistent or more uniquely identifiable.

Quick example in code:

import sys, ctypes, multiprocessing.util, readline

collected = []
def collector(event, *_args):
    collected.append(event)
sys.addaudithook(collector)

def test(fn, *args, **kw):
    collected.clear()
    fn(*args, **kw)
    if collected:  # Just check it's nonempty
        print("Success")
    else:
        print("Fail")

test(ctypes.memmove, 0, 0, 0)
test(ctypes.CFUNCTYPE(ctypes.py_object), ctypes._memmove_addr)
test(readline.read_history_file, __file__)
test(multiprocessing.util.spawnv_passfds, b"/bin/id", [], [])

CPython versions tested on:

3.11, 3.12, 3.13, CPython main branch

Operating systems tested on:

Linux

Linked PRs

• GH-115322: Add missing audit hooks #115624
• GH-115322: fix ctypes call_function audit hook on 32-bit platforms #132496

[gpshead]

• The _posixsubprocess.fork_exec function, and its only user in the standard library, multiprocessing.util.spawnv_passfds perform a

The primary user of that is subprocess, not just multiprocessing's spawn start method.

subprocess already has an audit hook of its own via sys.audit: https://github.com/python/cpython/blob/main/Lib/subprocess.py#L1827
Along those lines, it'd be simpler and consistent to just call sys.audit from within multiprocessing.util.spawnv_passfds, but I think your point of this issue was more to see it consistently done at the extension module API level?

There is symmetry in that the private _winapi.CreateProcess API also triggers an audit hook in addition to subprocess.Popen before it calls it so I'm okay with the concept of adding a _posixsubprocess.fork_exec audit event as your PR does.

[RobinJadoul]

Ah, yes, I have no idea how I missed subprocess when looking for callers...

It's indeed the goal to have some fewer "holes" or better coverage from the audit hooks here. That includes directly calling into the extension modules or callers that don't do their own hook (like the multiprocessing one).
In general, the closer to the actual operation happening, the less chance to miss it.

The new event was indeed based on the winapi ones.

[devdanzin]

Should _gdbm.open() also emit an audit event? It can be used to overwrite a file, besides creating a new one.

[RobinJadoul]

Looks like a good catch that should probably be covered too. It may need a bit of translation to not confuse existing consumers of the open event though, as the flags and mode are noticeably different in _gdbm.open.