Enabling and disabling auditing
Enable or Disable
from the main menu to switch auditing on or off.
The Enable function uses the current audit parameter file to perform the subsystem initialization. Disable exits gracefully from auditing (all collection files are read by the daemon and compacted). The daemon then terminates, leaving only an audit session log file and the session compaction files.
Most subsystem parameters can be modified while auditing is running, so you do not need to disable audit for that purpose. When auditing is enabled or disabled, a message is displayed indicating the status of auditing at reboot time; if disabled, auditing will be disabled at system startup and if enabled, auditing will be enabled again at startup.
There is an important consideration involving LUIDs and audit sessions. Example 6-2, ``Incomplete audit trail example'' is a section of an audit report that shows a denied file access, but with a user ID of root and not the unauthorized user ID that actually tried to access the file (in this case to touch the file /a).
Example 6-2 Incomplete audit trail example
Process ID: 227 (*INC*) Date/Time: Thu Dec 14 18:47:16 1989 Luid: root Euid: root Ruid: root Egid: root Rgid: root Event type: Access denial System call: Creat Object: /a Result: Failed-EACCES (Access denial) Security policy: discretionary
Note the (*INC*) next to the process ID. This indicates that the audit trail for this process is incomplete. It means that auditing was started after this user logged in, so there is no record of the LUID being set and the reduction program does not know what it is. The reduction program assigns a value of zero (root) to any unknown LUIDs. The audit session must include the login for the user being examined, or the audit subsystem does not have a record of the user ID. The only way to ensure this is to start auditing before users are allowed to log in. You should avoid starting an audit session while the system is already active.