Exécutables vs objets partagés

J'ai remarqué quelque chose en faisant find /bin -exec file {} \;:

la filecommande signale que certaines entrées dans /binsont shared objects, tandis que d'autres comme executables. Par exemple,

/ bin / ntfsck: objet partagé
ELF 64 bits LSB , x86-64, version 1 (SYSV), lié dynamiquement (utilise des bibliothèques partagées), pour GNU / Linux 2.6.24, BuildID [sha1] = 312d93fd0d8653e7236a61db2e67b93c63225a00, supprimé

Même rapport pour gawk

/ usr / bin / gawk: objet partagé
ELF 64 bits LSB , x86-64, version 1 (SYSV), lié dynamiquement (utilise des bibliothèques partagées), pour GNU / Linux 2.6.24, BuildID [sha1] = 76bb13aac7e212164bd6e0d7b8a5d92db44543c9, supprimé

En revanche, filepour /bin/echo:

/ bin / echo: exécutable
ELF 64 bits LSB , x86-64, version 1 (SYSV), lié dynamiquement (utilise des bibliothèques partagées), pour GNU / Linux 2.6.24, BuildID [sha1] = 193e75fc13e9c4599e772b8d79125a5934cf601c, supprimé

Essentiellement, je veux savoir quelle est la différence entre les executablefichiers et les shared objectfichiers.

Tl; dr

Il n'y a pas de différence, mis à part le fait qu'un exécutable compilé peut être lié à un objet partagé mais pas à un exécutable.

En général, il existe deux façons de compiler ¹ un exécutable:

• Utilisation de la liaison statique: les bibliothèques externes incluses dans le code source sont compilées et la bibliothèque compilée (ou l'objet dans la perspective du lieur) est ajoutée à l'exécutable lui-même;
• Utilisation de la liaison dynamique: les bibliothèques externes incluses dans le code source sont compilées mais un lien vers la bibliothèque compilée (ou l'objet dans la perspective du lieur) est ajouté à l'exécutable (et les bibliothèques / objets compilés sont chargés par l'éditeur de liens au moment de l'exécution si nécessaire);

Il y a des avantages / inconvénients à utiliser chacune de ces méthodes, mais ce n'est pas le but de la question;

• /bin/ntfscket /usr/bin/gawksont des objets partagés: cela signifie qu'un exécutable peut être compilé puis lié à eux pour utiliser leurs fonctionnalités;
• /bin/echoest un exécutable: cela signifie qu'un exécutable peut ne pas être compilé puis lié à lui pour utiliser ses fonctionnalités;

Alors /bin/ntfscket/usr/bin/gawk sont techniquement des bibliothèques compilées (ou des objets dans la perspective de l'éditeur de liens), mais, comme on aurait pu forsaw, rien empêche un objet partagé à partir en cours d' exécution comme un fichier exécutable.

Soit dit en passant, notez également que les filerapports (pour chacun d'eux):

lié dynamiquement (utilise des bibliothèques partagées)

Cela signifie que chacun d'eux est lié dynamiquement (et utilise probablement) à d'autres objets partagés également.

_{1. "Compiler" dans son acceptation plus large, qui comprend le prétraitement, la compilation et la liaison.}

Une autre différence est que les exécutables ont un décalage d'adresse de point d'entrée défini, c'est-à-dire 0x08048000 pour i386, 0x00400000 pour x86 et 0x00010000 pour armer.

Un fichier objet partagé peut être une bibliothèque, mais aussi un exécutable. Lorsqu'il s'agit d'un exécutable, il n'y a pas un tel décalage. Un exécutable d'objet partagé , pour ainsi dire, est un exécutable indépendant de position (PIE) utilisant la randomisation de la configuration de l'espace d'adressage (ASLR). Ainsi, lorsque vous regardez son fichier / proc / pid / maps, vous remarquerez que l'emplacement des segments chargés varie dans chaque exécution contrairement aux exécutables standard.

L'idée derrière cette fonctionnalité est d'ajouter de la sécurité aux exécutables en empêchant les attaquants d'effectuer des attaques de programmation orientées retour. De nombreux responsables ont décidé de créer des packages avec PIE activé par défaut, par exemple depuis Fedora 23 ou avec Ubuntu 17.10.