Executables vs Shared objects

Question

I noticed something while doing find /bin -exec file {} \; :

the file command reports some entries in /bin are shared objects , while others as executables . For instance,

/bin/ntfsck:
ELF 64-bit LSB shared object, x86-64, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=312d93fd0d8653e7236a61db2e67b93c63225a00, stripped

Same report for gawk

/usr/bin/gawk:
ELF 64-bit LSB shared object, x86-64, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.24,
BuildID[sha1]=76bb13aac7e212164bd6e0d7b8a5d92db44543c9, stripped

In contrast file for /bin/echo is:

/bin/echo:
ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.24,
BuildID[sha1]=193e75fc13e9c4599e772b8d79125a5934cf601c, stripped

Essentially, I want to know what is the difference between executable files and shared object files.

Solution 1

Tl;dr

There's no difference, aside from the fact that a compiled executable might be linked against a shared object but not against an executable.

---

In general, there are two ways to compile¹ an executable:

• Using static linking: external libraries included in the source code are compiled and the compiled library (or object in the linker's perspective) is added to the executable itself;
• Using dynamic linking: external libraries included in the source code are compiled but a link to the compiled library (or object in the linker's perspective) is added to the executable (and the compiled libraries / objects are loaded by the linker at run-time if needed);

There are advantages / disadvantages in using each of these methods, but that's not the point of the question;

• /bin/ntfsck and /usr/bin/gawk are shared objects: this means that an executable might be compiled and then linked against them to use their functionalities;
• /bin/echo is an executable: this means that an executable might not be compiled and then linked against it to use its functionalities;

So /bin/ntfsck and /usr/bin/gawk are technically compiled libraries (or objects in the linker's perspective), but, as one may have forsaw, nothing prevents a shared object from being run as an executable.

On a side note, notice also that file reports (for each of them):

dynamically linked (uses shared libs)

This means that each of them is dynamically linked to (and likely uses) other shared objects as well.

---

_{1. "Compile" intended in its broader acceptation, which includes preprocessing, compilation and linking.}

Solution 2

Another difference is that executables have a defined entry point address offset, i.e., 0x08048000 for i386, 0x00400000 for x86 and 0x00010000 for arm.

A shared object file can be a library, but also an executable. When being an executable, there is no such offset. A shared object executable, so to say, is a positional independent executable (PIE) using address space layout randomization (ASLR). Thus, when looking at its /proc/pid/maps file, you will notice that the location of the loaded segments vary in each execution in contrast to standard executables.

The idea behind this feature is to add security to executables by hindering attackers from performing return-oriented programmings attacks. Many maintainers decided to build packages with PIE enabled as the default, e.g., since Fedora 23 or with Ubuntu 17.10.

Comments

[Rinzwind]

en.wikipedia.org/wiki/Position-independent_code

[Dr.jacky]

dynamically linked to other shared objects , IN OS? or shared libraries in itself?!

[kos]

@Mr.Hyde In the OS, more specifically in locations that must be preconfigured in the linker, so that the linker can load them at run-time if needed. See here, chapter 3.2.

[Sergiy Kolodyazhnyy]

Interesting answer. Lacks a few sources ( would be nice if you added a few links, especially for the entry point part ) but I searched a few stackoverflow questions about that. But definitely good answer.

[Adham Zahran]

One can actually link against an executable using dlopen :D example

[user1502776]

So shared object can be run as executable and it has a main() symbol. It can also be linked with another executable which already has its main() symbol. How does this work out ?

[vincent163]

So I took an existing ELF executable and changed the two bytes at offset 0x10 from 0x2 to 0x3. This turns it into a shared object. I then ran the executable, but I could only get SIGSEGV. What is happening in this case if shared objects were equivalent to executables?