User Audit Fields in the audit_user File

If it is desirable to audit some users differently from others, the administrator may edit the audit_user file to add audit flags for individual users. If specified, these flags are combined with the system-wide flags specified in the audit control file to determine which classes of events to audit for that user. The flags the administrator adds to the user's entry in the audit_user file modify the defaults from the audit_control file in two ways: by specifying a set of event classes that are never to be audited for this user or by specifying a set of event classes that are always to be audited.

In the audit_user file entry for each user, there are three fields. The first field is the username, the second field is the always-audit field, and the third is the never-audit field. The two auditing fields are processed in sequence, so auditing is enabled by the first field and turned off by the second.

Avoid the common mistake of leaving the all set in the never-audit field. This causes all auditing to be turned off for that user, overriding the flags set in the always-audit field.

Using the never-audit flags for a user is not the same as removing classes from the always-audit set. For example, suppose (as shown in the examples below), you have a user fred for whom you want to audit everything except successful reads of file system objects. (This is a good way to audit almost everything for a user while generating only about three-quarters of the audit data that would be produced if all data reads were also audited.) You also want to apply the system defaults to fred. Here are two possible audit_user entries.

The correct entry:

fred:all,^+fr:

The incorrect entry:

fred:all:+fr

The first example says, "always audit everything except successful file-reads." The second example says "always audit everything, but never audit successful file-reads." The second example is incorrect because it overrides the system default. The first example achieves the desired effect: any earlier default applies, as well as what's specified in the audit_user entry.

Successful events and failed events are treated separately, so a process can (for example) generate more audit records when an error occurs than when the event is successful.