That’s the dynamic linker; if you run it on its own, it will tell you what it does:
Usage: ld.so [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...]
You have invoked ‘ld.so’, the helper program for shared library executables.
This program usually lives in the file /lib/ld.so
, and special directives
in executable files using ELF shared libraries tell the system's program
loader to load the helper program from this file. This helper program loads
the shared libraries needed by the program executable, prepares the program
to run, and runs it. You may invoke this helper program directly from the
command line to load and run an ELF executable file; this is like executing
that file itself, but always uses this helper program from the file you
specified, instead of the helper program file specified in the executable
file you run. This is mostly of use for maintainers to test new versions
of this helper program; chances are you did not intend to run this program.
The linker is used to run dynamically-linked programs. When you run chmod
, the kernel effectively runs the equivalent of /lib64/ld-linux-x86-64.so.2 /bin/chmod
, as you did manually; the latter works even if the chmod
binary isn’t executable because the check for execute permission is done by the execve()
system call on the file that it is being told to execute and in the /lib64/ld-linux-x86-64.so.2 /bin/chmod
shell command line, the path passed by the shell to execve()
is /lib64/ld-linux-x86-64.so.2
, not /bin/chmod
, and it’s the one that is checked for execute permission, /bin/chmod
is only passed as an argument to the linker. It's the same thing in /bin/sh ./some-script
where ./some-script
doesn't need to be executable.
You’ll find much more detail on this in the excellent How programs get run: ELF binaries article.