Bug #3230 should check default paths for DT_DEPAUDIT

Added by Robert Mustacchi about 8 years ago. Updated about 8 years ago.

cmd - userland programs
Start date:
Due date:
% Done:


Estimated time:
Gerrit CR:


When the runtime linker considers a secure binary (a setuid or setguid binary which doesn't match your id) then it has special handling for libraries which are loaded from the environment – these libraries must appear in the secure path. Libraries that are in a program's DT_NEEDED section are exempt from these checks. Traditionally audit libraries are loaded via using LD_AUDIT; however, one can also use -P to specify an audit library for an object. The resulting object has the dynamic library end up in its DT_DEPAUDIT section. This audit library is required for the object to function at all. The runtime linker however does not distinguish between an audit library that is in the DT_DEPAUDIT and an audit library that is in the LD_AUDIT section. However, it does distinguish between a library that is in the DT_NEEDED and a library that is added via LD_PRELOAD.

In this case, because of the hard dependency on the audit library, we should not have to search the secure path for said library. Instead, if an audit library comes from the DT_DEPAUDIT section, then it should be considered the same as a library in the DT_NEEDED section of a library. This means that libraries that are in the DT_DEPAUDIT section, like DT_NEEDED, will use the default search path and not the 'secure' search path.


Updated by Robert Mustacchi about 8 years ago

  • Status changed from New to Resolved
  • % Done changed from 90 to 100

Resolved in 13841:38a9b4eba5af.

Also available in: Atom PDF