This answer is only valid for a GNU/Linux environment.
From comments, OP's binary has privilege features added to it: capabilities. This switchs
ld.so(8) into secure-execution mode which by default disables most dynamic-linker related environment variables, including
For security reasons, if the dynamic linker determines that a binary
should be run in secure-execution mode, the effects of some
environment variables are voided or modified [...]
A binary is executed in secure-execution mode if [...] including:
The process's real and effective user IDs differ, or the real and effective group IDs differ. [...]
A process with a non-root user ID executed a binary that conferred capabilities to the process.
However, with root access on the system it's possible to configure it to meet the prerequisites of secure-execution mode for these two parameters when run as non-root, still as described in
In secure-execution mode, preload pathnames containing slashes are
ignored. Furthermore, shared objects are preloaded only from the
standard search directories and only if they have set-user-ID mode bit
enabled (which is not typical).
What are the standard search directories? They are provided with the output of
ld.so --help. For example on a Debian amd64/x86_64:
$ ld.so --help
Shared library search path:
(libraries located via /etc/ld.so.cache)
/lib/x86_64-linux-gnu (system search path)
/usr/lib/x86_64-linux-gnu (system search path)
/lib (system search path)
/usr/lib (system search path)
In the end the shared object file must be in one of these places. From testing it :
- doesn't have to be owned by root, as long as it has mode
- can be a symlink pointing to the actual
u+s file in any place as long as the symlink is in the right place.
- no path should be present in
LD_PRELOAD, only (a) filename(s) without
- if the binary's capabilities don't grant it arbitrary access to read a file, the shared object can have its mode set so that it allows only a single user or a group (typically
chmod o-rwx should be applied and the correct ownership set, then
u+s restored). For setuid-root or
CAP_DAC_READ_SEARCH this probably won't prevent the library to be used by any user executing such privileged binary.
Since glibc 2.3.4,
LD_DEBUG is ignored in secure-execution mode,
unless the file
/etc/suid-debug exists (the content of the file is
I didn't find a way to restrict it to only an user or group.
Example (with root access using
$ sudo touch /etc/suid-debug
$ sudo cp -aiL ./lib.so /usr/lib/lib.so
$ sudo chmod u+s /usr/lib/lib.so
which now allows to run as normal user with both variables taken into account:
LD_DEBUG=all LD_PRELOAD=lib.so ./big_app