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 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
.
Note:
Auditing can be disabled at runtime by setting the environment variableLD_NOAUDIT
to a non-null value.