ldd equivalent which fail when library not found

Question

Assume I perform ldd /bin/ls with the pthread library removed. I obtain

linux-vdso.so.1 (0x00007ffcc3563000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f87e5459000)
libcap.so.2 => /lib64/libcap.so.2 (0x00007f87e5254000)
libc.so.6 => /lib64/libc.so.6 (0x00007f87e4e92000)
libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f87e4c22000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f87e4a1e000)
/lib64/ld-linux-x86-64.so.2 (0x00005574bf12e000)
libattr.so.1 => /lib64/libattr.so.1 (0x00007f87e4817000)
libpthread.so.0 => not found

The return code is zero. Is there a command returning an error in this case? Something similar to

#!/bin/bash
if [[ ! -z $(ldd ${target} | grep 'not found') ]]; then
 exit 1
fi

Answer 1

Take care with ldd on linux; it's just a bash script which, at least on older systems, will run the given program with LD_TRACE_LOADED_OBJECTS=1 in its environment.

This means that if the program has other interpreter than /lib{64,32}/ld-*, that program will be run with your target as its first argument, even if you didn't mean to do it. If you run ldd on an executable owned by some other user, that user will own you instead.

You can check what interpreter is defined in the ELF headers with readelf -l "$target" | grep interpreter.

On newer systems, ldd has been changed to pass the target as argument to an interpreter taken from a list of 'good' interpreters (eg. /lib64/ld-linux.so.2 target); I don't find that convincing, but it's up to you to make the determination if that's safe enough.

If you find all that acceptable, the simplest way to do it is:

if ldd "$target" | grep -q 'not found'; then
 echo >&2 "$target is missing dependencies"
 exit 1
fi

If called in 'trace mode' (as from ldd), the default dynamic loader on linux will always exit with a 0 status, and there's no way to change that via command line switches or environment variables; you'll have to change its source code.

• Stephen Kitt: See also CVE-2009-5064.
• Stephen Kitt: Just out of curiosity, what would it take for you to find "that" convincing?
• user313992: Nothing -- ld.so is complex enough so that's no safe way to run in 'dry' mode with unknown binaries. Of course you won't find spectacular exploits against it, because it wasn't a real security issue in the first place, so it's not worth bothering with; no sysadmin worth their two bits would use ldd against random binaries.
• RubberStamp: From the ldd man page ... safer to use objdump -p /path/to/program |grep NEEDED instead.
• user313992: @RubberStamp compare the output of objdump -p /usr/bin/xeyes | grep NEEDED to ldd /usr/bin/xeyes. Shared objects depend on other shared objects.