- while system call is executing, additional information is
collected
based on the data copied from userspace by the syscall. In the case of
filesystem operation, this would be the audit attribute associated with
the inode being worked on.
This might be a little insane, that is, from the current syscall
audit, to figure out "the inode being worked on." In ptrace there is
an audit_syscall_enter hook and audit_syscall_exit hook. In neither
hook is there a reasonable way to discover the inode associated with
the syscall argument. This is why I think its easiest to do the
logging in the VFS for this portion of the record, at least... At this
point, we have a dentry associated with an inode (the inode we're
interested in), to work with.
- when the system call is complete, the filter rules are applied to
the
available data (including the additional info), and an audit record
is generated and sent to userspace.
In my way, this wouldn't work to well because the syscall could be
filtered away and the VFS portion would be in userland waiting...
-Tim
Linux-audit mailing list
Linux-audit(a)redhat.com
http://www.redhat.com/mailman/listinfo/linux-audit
--
- Timothy R. Chavez