"open" audit event does not report dir_fd

[bemoody]

The "open" audit event is supposed to allow auditing hooks to detect when a file is opened by the open or os.open functions.

However, if os.open is called with a dir_fd argument, that information is not conveyed to the auditing hook. In this case, the arguments passed to the auditing hook are misleading.

Consider the following:

import sys, os

def myaudithook(event, args):
    if 'open' in event:
        print(event, repr(args))

sys.addaudithook(myaudithook)
a = open("/etc/motd", "r")
b = os.open("/etc/motd", os.O_RDONLY)
c = os.open("/etc", os.O_RDONLY)
d = os.open("motd", os.O_RDONLY, dir_fd=c)

Currently, this prints:

open ('/etc/motd', 'r', 524288)
open ('/etc/motd', None, 524288)
open ('/etc', None, 524288)
open ('motd', None, 524288)

The fourth line is a problem: there's nothing to indicate that we are not, in fact, trying to open the file "motd" in the current working directory. From the point of view of the auditing hook, this is highly misleading.

My suggestions:

1. The "open" audit event could be changed to add an additional dir_fd argument, so the above would give:

open ('/etc/motd', 'r', 524288, None)
open ('/etc/motd', None, 524288, None)
open ('/etc', None, 524288, None)
open ('motd', None, 524288, 5)

This would be an API break, so probably not a good idea, but I mention it for completeness.

2. A new auditing event could be defined to handle "openat" events:

open ('/etc/motd', 'r', 524288)
open ('/etc/motd', None, 524288)
open ('/etc', None, 524288)
openat ('motd', None, 524288, 5)

This would arguably maximize backward compatibility (and be easy to implement in CPython) but would make life more complicated for developers implementing audit hooks.

3. In the event that a dir_fd is specified, it could be incorporated into the first (path) argument:

open ('/etc/motd', 'r', 524288)
open ('/etc/motd', None, 524288)
open ('/etc', None, 524288)
open ((5, 'motd'), None, 524288)

This looks a little bit weird. But it's consistent with the current API:

• If an existing audit hook doesn't care about the path (only mode and flags), then this works exactly as before.

• Existing general-purpose audit hooks cannot assume the first argument is always str: it could be bytes, or in the case of "fdopen", it could be int.

• Existing audit hooks that rely on the path argument to give accurate information are already broken in the presence of dir_fd. This wouldn't make them any more or less broken.