The audit_user File

If it is desirable to audit some users differently from others, the administrator can 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.

So, what is audited for an individual user is the combination of the workstation audit flags and the user's always and never audit flags, as shown below.

What is audited = (Workstation Audit Flags + User's Always Audit) - User's Never Audit

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, 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 katya 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 katya. Here are two possible audit_user entries.

The correct entry

katya:all,^+fr:

The incorrect entry:

katya: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 is 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.

Dynamic controls refer to controls put in place by the administrator while processes are running. These persist only while the affected processes (and any of their children) exist, but will not continue in effect at the next login. Dynamic controls apply to one workstation at a time, since the audit command only applies to the current workstation where you are logged in.

Each process has two sets of one-bit flags for audit classes. One set controls whether the process is audited when an event in the class is requested successfully; the other set, when an event is requested but fails (for any reason). It is common for processes to be more heavily audited for failures than for successes, since this can be used to detect attempts at browsing and other types of attempts at violating system security.