Re: [PATCH 0/2] audit string fields interface + consumer
I received some questions in IRC, so I thought I'd follow up with a
better description of the AUDIT_WATCH filter.
On Wed, Jan 11, 2006 at 06:05:39PM -0500, Amy Griffis wrote:
With the AUDIT_WATCH field, userspace may specify a path filter,
akin
to specifying an inode filter. If a filename exists at the specified
path, audit records will be generated as they are for inode filters.
If a filename does not exist at the specified path, the rule will be
added, but no records will be generated.
With the functionality present in this patch, a user may specify any
absolute path, of which all, some, or none of the path components
actually exist on the filesystem.
Audit will attempt to resolve the path to an inode for the last
component. If it succeeds, the resulting inode # is used for the
AUDIT_WATCH filter. If it fails, an invalid value (-1) is used for
the AUDIT_WATCH filter. After the rule is inserted, it does not
change and the AUDIT_WATCH filter behaves identically to the
AUDIT_INODE filter. Therefore, if audit is unable to resolve the path
when inserting the rule, the rule is meaningless.
This implementation is incomplete in the following ways. First, we
wish to limit the paths that can be "watched" to those having existing
dentry parents in the filesystem. This limitation will be enforced in
the next patch set. Additionally, we wish to audit watched
files/directories as they come and go in the filesystem. This feature
will also be added in the next patch set.
In the next patch set, I will provide the functionality necessary to
support persistence for path-based filters (aka watches). This will
enable audit to generate audit records whenever an inode exists at the
specified path.
The next patch set will contain a kernel API for Inotify, and some
corresponding client code in audit. This will enable audit to receive
the information it needs about filesystem events that may require it
to modify one or more AUDIT_WATCH filters.
This implementation will require the existence of a dentry parent for
the last component of any path specified with AUDIT_WATCH. If an
inode corresponding to the last path component exists at the time of
rule insertion, the AUDIT_WATCH filter will be set to that inode #.
If an inode does not exist, the AUDIT_WATCH filter will contain the
invalid value (-1). This behavior is similar to the current patch,
with the exception that the AUDIT_WATCH filter will be updated based
on relevant filesystem events.
Audit will register with Inotify all of the dentry parents for paths
that have been specified with AUDIT_WATCH. Audit will be interested
in filesystem events that indicate that a "child" of one of these
parents has been created or removed, or that one of the parents has
been removed.
When audit receives indication that a "child" has been created, it
will update any relevant AUDIT_WATCH filters with the new inode #.
When audit receives indication that a "child" has been removed, it
will update any relevant AUDIT_WATCH filters with the invalid value
(-1). When audit receives indication that a registered dentry parent
has been removed, it will implicitly remove any audit rules that refer
to one of the parent's children and log a message for each rule
removed.
It may be desirable to log a message when audit modifies the value in
an AUDIT_WATCH filter. However, I can see this generating a lot of
log traffic depending on the files being watched. If we decide to log
a message, we should probably make it configurable.
Hope this helps.
Amy