Invoking the Auditing Interface

The rtld-audit interface is enabled by one of two means. Each method implies a scope to the objects that are audited.

• Local auditing is enabled through dynamic entries recorded within an object at the time the object was built. The audit libraries that are made available by this method are provided with information in regards to those dynamic objects that are identified for auditing.

• Global auditing is enabled using the environment variable LD_AUDIT. Global auditing can also be enabled for an application by combining a local auditing dynamic entry with the -z globalaudit option. The audit libraries that are made available by these methods are provided with information regarding all dynamic objects used by the process.

Either method of invocation consists of a string that contains a colon-separated list of shared objects that are loaded by dlopen(3C). Each object is loaded onto its own audit link-map list. Each object is searched for audit routines using dlsym(3C). Audit routines that are found are called at various stages during the applications execution.

The rtld-audit interface enables multiple audit libraries to be supplied. Audit libraries that expect to be employed in this fashion should not alter the bindings that would normally be returned by the runtime linker. Alteration of these bindings can produce unexpected results from audit libraries that follow.

Secure applications can only obtain audit libraries from trusted directories. By default, the only trusted directories that are known to the runtime linker for 32–bit objects are/lib/secure and /usr/lib/secure. For 64–bit objects, the trusted directories are /lib/secure/64 and /usr/lib/secure/64.

Auditing can be disabled at runtime by setting the environment variable LD_NOAUDIT to a non-null value.