On Wed, Dec 15, 2004 at 09:29:05AM +1100, Leigh Purdie wrote:
If you store audit attributes as a real file-system attribute:
* You're unlikely to be able to audit files on non-native filesystems
(eg: VFAT, CDROM, or USBKeys) - one audit objective that is very popular
in intelligence circles, for example, is "What has been copied out to
removable media?"
Note that it would be fairly easy to do all-or-nothing audit for
non-native filesystems based on the properties of the mount point or
filesystem type, so the removable media example is not necessarily a
problem if treated as a special case.
If you retain a 'virtual' attribute within the audit
subsystem:
* Your CPU usage increases, as you have to go through the full inode ->
real path chain to form a full directory path, before comparing the
directory path against the user's filters. (eg: "Tell me whenever
someone writes a file to /media/usbkey/.*")
Your suggestion is based on the audit system storing paths as the virtual
attributes, and using these for comparisons. The LAuS (SuSE) audit system
works roughly this way, using a prefix() predicate on (canonicalized)
path name arguments.
One approach we had also been discussing had been to attach the
properties to in-memory dentry or inode objects for individual files and
directores, in essence an in-memory overlay of additional attributes over
the existing file tree. This is of course only feasible if the number of
objects with individual audit attributes is small enough to not use too
much memory. That would have runtime characteristics similar to the real
filesystem attributes, and would also not necessarily offer the
flexibility of the path-based one you mention. I think that the consensus
was that this appears to be too complex compared to the simple filesystem
extended attributes.
-Klaus