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 by defining one or more auditors at the time the object is built. See Recording Local Auditors. The audit libraries that are made available at runtime by this method are provided with information regarding the dynamic objects that have requested local auditing.
Global auditing is enabled by defining one or more auditors using the environment variable LD_AUDIT. Global auditing can also be enabled for an application by combining a local auditing definition with the –z globalaudit option. See Recording Global Auditors. The audit libraries that are made available at runtime by these methods are provided with information regarding all dynamic objects used by the application.
Both methods of defining auditors employ a string consisting of a colon-separated list of shared objects that are loaded by dlmopen(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.
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.