To start auditing, audit_log_start needs to be called. The associated code flow diagram can be seen in Figure 19-5.
Basically, the job of audit_log_start is to set up an instance of audit_buffer and return it to the caller; but before this, the backlog limit and rate limit need to be considered.
The maximal length of the backlog queue (i.e., the queue where the finished audit records are stored) is given by the global variable audit_backlog_limit. If this number is surpassed,5 audit_log_start schedules a timeout and retries the operation afterward, hoping that the backlog has been reduced in the meantime. Additionally, a rate check ensures that not more than a certain number of messages are sent per second. The global variable audit_rate_limit) determines the maximal frequency. If this frequency is surpassed, a message that indicates this condition is sent to the daemon and allocation is aborted. These measures are necessary to avoid denial-of-service attacks, and to provide protection against audit events that occur with too-high frequency.
If backlog and rate limits allow the creation of new audit buffers, audit_buffer_alloc is used to do what its name says — allocate an audit_buffer instance. Before the buffer is returned to the caller, audit_get_stamp provides a unique serial number, and an initial log message that contains the creation time and the serial number is written to the buffer.
Continue reading here: Writing Log Messages
Was this article helpful?