Decoding arguments passed to system calls

[Darryl Dixon - Winterhouse Consulting]

Hi List,

Forgive me if this isn't the correct forum for this, but I'd like to
present a scenario, outline my hypothetical solution to it, and then
solicit for feedback from the list on how to actually achieve it. I have
seen various discussions on the list around this topic (eg
http://www.redhat.com/archives/linux-audit/2005-March/msg00221.html, and
the current "Absolute path names in PATH records" thread), but
they all seemed intertwined with other things, so I am asking here to try
and pin down a firm answer :)

Scenario:
A very large filesystem with potentially millions of files in an ad-hoc,
unordered directory structure. The requirement is to be able to audit any
action on any file in this filesystem (moves, adds, changes, deletes,
etc). In auditfs terms, there is a requirement to have a 'watch' on every
single file (millions of files), and on any new file that is added.

Hypothetical solution:
Clearly, scanning the filesystem with `find` and adding calling auditctl
with the appropriate arguments to generate a watch on every singly file is
totally infeasible (find takes almost an hour to run, and in the meantime
stuff is potentially changing...). Instead, I envision it would make
better sense to simply audit every call to write(), open(), rename(), etc,
and then filter backwards from there with ausearch and a filter based on
the path. On Solaris with BSM, this is possible. My problem is that this
doesn't seem possible with the Linux Audit subsystem, as the arguments to
the system calls are not decoded (eg, the audit records for write()
include only an opaque filehandle and pointer to the written data, etc).

So, in terms of feedback:

1) Am I totally wrong and there's a method of getting this information
already that I have overlooked?

2) Knowing very little about the auditing subsystem, and the kernel
internals in general I envision that decoding the filehandle into a path
is something that would need to be done in the kernel, and is impossible
from userland. Is this the case?

3) How much work do you all estimate that it would actually take to be
able to generate this information? Is it even possible without a major
architectural overhaul of the audit subsystem?

Any and all feedback much appreciated.

many regards,
Darryl Dixon
Winterhouse Consulting Ltd
http://www.winterhouseconsulting.com