RE: audit 0.6 release
> Tom can correct me here, but I suspect that ideally:
> * symlinks and links should be resolved. (even if the file linked to
> no longer actually exists - the final path name should still be
> reported/filtered on). Ideally, access to an symlink will actually
> generate TWO events - one for the symlink (open - read), one for the
> final file (open - as per user requirement).
That's a meaningful statement for symlinks but not for hard links. With
hard links there is no one 'final path name'; they're all just different
names for the same inode. If I hard-link /etc/passwd to /tmp/fish then
both of those are _real_ names for it.
It would be almost impossible to implement a system which is asked to
log 'all access to /etc/*' and includes in that the access to /tmp/fish.
Fair enough - I don't think anyone would begrudge us not performing
miracles. ;) We'll just have to note it as a limitation in the doco, and
let the end-user decide what they want to do.
For some, they'll accept the risk that the file won't be audited (most
will be in this category). Others may decide to turn on 'hard link
auditing' for normal user accounts to get an indication that this might
be happening. The more paranoid, may decide to audit all links, and file
accesses, and post-process the log data to track down all file-opens to
particular files (once resolved in the post-processing.. erm..
process. :)
Regards,
Leigh.
--
Leigh Purdie, Director - InterSect Alliance Pty Ltd
http://www.intersectalliance.com/