Recording Local Auditors

Local auditing requirements can be established when an object is built using the link-editor options -p or -P. For example, to audit libfoo.so.1, with the audit library audit.so.1, record the requirement at link-edit time using the -p option:

$ cc -G -o libfoo.so.1 -Wl,-paudit.so.1 -K pic foo.c
$ dump -Lv libfoo.so.1 | fgrep AUDIT
[3]    AUDIT      audit.so.1

At runtime, the existence of this audit identifier results in the audit library being loaded and information being passed to it regarding the identifying object.

With this mechanism alone, information such as searching for the identifying object has occurred prior to the audit library being loaded. To provide as much auditing information as possible, the existence of an object requiring local auditing is propagated to users of that object. For example, if an application is built that depends on libfoo.so.1, then the application is identified to indicate its dependencies require auditing:

$ cc -o main main.c libfoo.so.1
$ dump -Lv main | fgrep AUDIT
[5]    DEPAUDIT   audit.so.1

The auditing enabled via this mechanism results in the audit library being passed information regarding all of the applications explicit dependencies. This dependency auditing can also be recorded directly when creating an object by using the link-editor's -P option:

$ cc -o main main.c -Wl,-Paudit.so.1
$ dump -Lv main | fgrep AUDIT
[5]    DEPAUDIT   audit.so.1

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