Recording Local Auditors

Local auditing requirements can be established when an object is built using the link-editor options -p or -P. A developer wishing to audit the use of a shared object libfoo.so.1, with the audit library audit.so.1, can do so by recording this requirement at link-edit time using the -p option:

$ cc -G -o libfoo.so.1 -Wl,-paudit.so.1 -Kpic 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.

However, with this mechanism alone, information such as searching for the identifying object, will have 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 it will be 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

Note that the auditing enabled via this mechanism will result in the audit library being loaded and information being passed to it regarding all of the applications explicit dependencies. This dependency auditing can also be recorded directly when creating an object by using the link-editors' -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.