Decoding arguments passed to system calls

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