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 $ elfdump -d libfoo.so.1 | grep AUDIT [2] AUDIT 0x96 audit.so.1
At runtime, the existence of this audit identifier results in the audit library being loaded. Information is then passed to the audit library regarding the identifying object.
With this mechanism alone, information such as searching for the identifying
object occurs 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 with a
dependency on libfoo.so.1
, then the application is identified
to indicate its dependencies require auditing.
$ cc -o main main.c libfoo.so.1 $ elfdump -d main | grep AUDIT [4] DEPAUDIT 0x1be audit.so.1
The auditing enabled through 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 $ elfdump -d main | grep AUDIT [3] DEPAUDIT 0x1b2 audit.so.1