Provided by: manpages-fr-dev_4.13-4_all 
NOM
execve - Exécuter un programme
SYNOPSIS
#include <unistd.h>
int execve(const char *chemin, char *const argv[],
char *const envp[]);
DESCRIPTION
execve() exécute le programme auquel renvoie pathname. Il s'ensuit que le programme en
cours d'exécution par le processus appelant sera remplacé par un nouveau programme, avec
une pile, un tas et des segments de données (initialisés ou non) nouvellement initialisés.
pathname doit être soit un exécutable binaire, soit un script qui commence par une ligne
sous la forme :
#!interpréteur [argument-optionnel]
Pour des détails sur ce dernier cas, consultez « Scripts » ci‐dessous.
argv est un tableau de pointeurs vers des chaînes passées au nouveau programme en tant
qu'arguments de la ligne de commande. Par convention, la première de ces chaînes (à savoir
argv[0]) devrait contenir le nom de fichier associé au fichier étant exécuté. Le tableau
argv doit se terminer par un pointeur NULL (ainsi, dans le nouveau programme, argv[argc]
vaudra NULL).
envp est un tableau de pointeurs vers des chaînes, ayant par convention la forme
clé=valeur, qui sont passés au nouveau programme en tant qu'environnement. Le tableau envp
dois se terminer par un pointeur NULL.
Le vecteur d'argument et l'environnement sont accessibles à la fonction principale du
nouveau programme quand elle est définie ainsi :
int main(int argc, char *argv[], char *envp[])
Notez, cependant, que l'utilisation d'un troisième argument dans la fonction principale
n'est pas spécifiée dans POSIX.1, selon laquelle l'environnement doit être accessible par
la variable externe environ(7).
En cas de réussite, execve() ne renvoie rien et les segments de texte, les données
initialisées et non initialisées « bss »), ainsi que la pile du processus appelant sont
remplacés par ceux du programme chargé.
Si l'on effectuait un ptrace(2) sur le programme actuel, un signal SIGTRAP lui est envoyé
après la réussite de execve().
Si le bit set-user-ID est positionné sur le fichier du programme auquel renvoie pathname,
l'ID de l'utilisateur effectif du processus appelant passe à celui du propriétaire du
programme. De même, lorsque le bit set-group-ID est positionné sur le fichier du
programme, l'ID du groupe effectif du processus appelant est modifié pour correspondre à
celui du groupe du fichier.
Les transformations précitées des ID effectifs ne sont pas effectuées (c'est-à-dire que
les bits set-user-ID et set-group-ID sont ignorés) si un des éléments suivants est vrai :
– l'attribut no_new_privs est défini pour le thread appelant (voir prctl(2)) ;
– le système de fichiers sous-jacent est monté en nosuid (le drapeau MS_NOSUID de
mount(2)) ;
– ou un ptrace va être appliqué au processus appelant.
Les capacités du fichier du programme (voir capabilities(7)) sont également ignorées si un
des éléments ci-dessus est vrai.
L'UID effectif du processus est copié dans le Set-UID sauvegardé ; de la même manière, le
GID effectif est copié dans le Set-GID sauvegardé. Ces copies ont lieu après toute
modification d'ID effectif à cause des bits de permission Set-UID et Set-GID.
L'UID et le GID réel du processus ainsi que ses ID de groupe complémentaires ne sont pas
modifiés par un appel à execve().
Si l'exécutable est un fichier binaire a.out lié dynamiquement, et contenant des appels
aux bibliothèques partagées, l'éditeur de liens dynamiques de Linux ld.so(8) est appelé au
début de l'exécution, afin de charger les bibliothèques partagées nécessaires en mémoire
et d'effectuer l'édition des liens de l'exécutable avec eux.
Si l'exécutable est au format ELF lié dynamiquement, l'interpréteur indiqué dans le
segment PT_INTERP sera invoqué pour charger les bibliothèques partagées. Cet interpréteur
est généralement /lib/ld-linux.so.2 pour les fichiers binaires liés avec la glibc (voir
ld-linux.so(8)).
Effets sur les attributs de processus
Tous les attributs de processus sont préservés lors d'un execve(), à l'exception des
suivants :
– Les signaux pour lesquels le processus avait placé un gestionnaire sont réinitialisés à
leur valeur par défaut (consultez signal(7)).
– L'éventuelle pile spécifique pour les gestionnaires de signal n'est pas conservée
(sigaltstack(2)).
– Les projections en mémoire ne sont pas conservées (mmap(2)).
– Les segments de mémoire partagée System V sont détachés (shmat(2)).
– Les objets de mémoire partagée POSIX sont supprimés (shm_open(3)).
– Les descripteurs de files de messages POSIX ouverts sont fermés (mq_overview(7)).
– Les sémaphores nommés POSIX ouverts sont fermés (sem_overview(7)).
– Les temporisations POSIX ne sont pas conservées (timer_create(2)).
– Les flux de répertoires ouverts sont fermés (opendir(3)).
– Les verrouillages de mémoire ne sont pas préservés (mlock(2), mlockall(2)).
– Les gestionnaires de terminaison ne sont pas préservés (atexit(3), on_exit(3)).
– L'environnement de travail en virgule flottante est réinitialisé à celui par défaut
(consultez fenv(3)).
Les attributs de processus listés ci-dessus sont spécifiés dans POSIX.1. Les attributs de
processus spécifiques à Linux suivants sont également réinitialisés lors d'un execve() :
– L'attribut « dumpable » du processus est positionné sur la valeur 1, sauf si un
programme set-user-ID, set-group-ID ou en ayant les capacités est exécuté, auquel cas
l'attribut dumpable peut, au contraire, être réinitialisé à la valeur dans
/proc/sys/fs/suid_dumpable, dans les circonstances décrites sous PR_SET_DUMPABLE dans
prctl(2). Remarquez que les modifications d'un attribut « dumpable » peut entraîner le
passage du propriétaire des fichiers du répertoire /proc/[pid] de processus à
root:root, comme décrit dans proc(5).
– L'attribut PR_SET_KEEPCAPS de prctl(2) est effacé.
– (Depuis Linux 2.4.36 ou 2.6.23) Si un programme setuid ou setgid est exécuté, alors le
signal de mort de son parent défini par l'attribut PR_SET_PDEATHSIG de prctl(2) est
effacé.
– Le nom du processus, positionné par prctl(2) PR_SET_NAME (et affiché avec ps -o comm),
est réinitialisé avec le nom du nouvel exécutable.
– L'attribut securebits SECBIT_KEEP_CAPS de prctl() est effacé. Consultez
capabilities(7).
– Le signal de terminaison est réinitialisé à SIGCHLD (consultez clone(2)).
– La table des descripteurs de fichier n'est pas partagée, ce qui annule les effets de
l'attribut CLONE_FILES de clone(2).
Notez également les points suivants :
– Tous les threads autres que l'appelant sont détruits lors d'un execve(). Les mutex, les
variables de condition, et les autres objets de pthreads sont détruits.
– L'équivalent de setlocale(LC_ALL, "C") est exécuté au démarrage du programme.
– POSIX.1 indique que les actions pour les signaux ignorés ou placés à la valeur par
défaut ne sont pas modifiées. Une exception est néanmoins spécifiée dans POSIX.1 : si
SIGCHLD est ignoré, l'implémentation peut laisser l'action inchangée ou la replacer à
la valeur par défaut ; Linux ne modifie pas l'action.
– Toutes les opérations d'E/S asynchrones en cours sont annulées (aio_read(3),
aio_write(3)).
– Pour le traitement des capacités lors d'un execve(), consultez capabilities(7).
– Par défaut, les descripteurs de fichier restent ouverts au travers d'un execve(). Les
descripteurs marqués close-on-exec sont fermés ; consultez la description de FD_CLOEXEC
dans fcntl(2). (Si un descripteur de fichier est fermé, cela cause la libération de
tous les verrous d'enregistrement obtenus sur le fichier correspondant par ce
processus. Consultez fcntl(2) pour les détails.) POSIX.1 indique que si les
descripteurs de fichiers 0, 1 et 2 devaient être fermés après un execve() réussi, et
que le processus devient privilégié en raison d'un bit set-user-ID ou set-group-ID sur
le fichier exécuté, le système peut ouvrir un fichier non indiqué pour chacun de ces
descripteurs. En général, aucun programme portable, privilégié ou pas, ne peut
considérer que ces trois descripteurs resteront fermés après un execve().
Scripts
Un script d’interpréteur est un fichier textuel dont le bit d'exécution est activé et dont
la première ligne est de la forme :
#!interpréteur [argument-optionnel]
L’interpréteur doit être le chemin valable d'un fichier exécutable.
Si l'argument pathname de execve() indique un script interprété, l'interpréteur sera
appelé avec les arguments suivants :
interpréteur [argument-optionnel] pathname arg...
où pathname est le chemin absolu du fichier indiqué en premier argument de execve(), et
arg... est la série de mots vers lesquels pointe l'argument argv de execve(), à partir de
argv[1]. Remarquez qu'il n'y a aucune manière d'obtenir argv[0] passé à l'appel execve().
Pour être portable, argument-optionnel doit soit être absent, soit être un seul mot
(c'est‐à‐dire ne pas contenir d'espace) ; consultez les NOTES ci‐dessous.
Depuis Linux 2.6.28, le noyau autorise l'interpréteur de script à être lui-même un script.
Cette autorisation est récursive jusqu'à quatre niveaux, pour qu'un interpréteur puisse
être interprété par un script qui est interprété par un script, et ainsi de suite.
Limites sur la taille des paramètres et d'environnement
La plupart des implémentations UNIX imposent des limites sur la taille totale des chaînes
des paramètres des lignes de commande (argv) et de l'environnement (envp) qui peuvent être
passées à un nouveau programme. POSIX.1 permet à une implémentation d'annoncer cette
limite en utilisant la constante ARG_MAX (soit définie dans <limits.h>, soit disponible à
l'exécution en utilisant l'appel sysconf(_SC_ARG_MAX)).
Sur les noyaux Linux antérieurs à 2.6.23, la mémoire utilisée pour stocker les chaînes
d'environnements et d'arguments était limitée à 32 pages (définie par la constante noyau
MAX_ARG_PAGES). Sur les architectures dont la taille de page est 4 Ko, cela donne un
maximum de 128 Ko.
Sur les noyaux 2.6.23 et ultérieurs, la plupart des architectures ont une limite de taille
dérivée de la limite de ressources souple RLIMIT_STACK (consultez getrlimit(2)) qui est en
vigueur au moment de l'appel à execve() (ce n'est pas le cas pour les architectures sans
unité de gestion mémoire : elles conservent la limite des noyaux antérieurs à 2.6.23). Ce
changement permet aux programmes d'avoir une liste de paramètres ou un environnement
beaucoup plus grand. Pour ces architectures, la taille totale est limitée à 1/4 de la
taille de pile permise (imposer une limite de 1/4 permet d'assurer que le nouveau
programme garde de l'espace pour la pile). De plus, la taille totale est limitée à 3/4 de
la valeur de la constante _STK_LIM du noyau (8 Mio). Depuis Linux 2.6.25, le noyau place
une limite inférieure de 32 pages à cette limite de taille, de telle sorte que même si
RLIMIT_STACK est très faible, il est garanti aux applications qu'elles auront au moins
autant de place pour les paramètres et leur environnement que ce qui était fourni par
Linux 2.6.23 et les précédents (cette garantie n'était pas présente dans les noyaux 2.6.23
et 2.6.24). De plus, la limite par chaîne est de 32 pages (la constante noyau
MAX_ARG_STRLEN), et le nombre maximal de chaînes est de 0x7FFFFFFF.
VALEUR RENVOYÉE
En cas de réussite, execve() ne renvoie rien, en cas d'échec il renvoie -1 et errno
contient le code d'erreur.
ERREURS
E2BIG Le nombre total d'octets dans l'environnement (envp) et la liste d'arguments (argv)
est trop grande.
EACCES Le droit de parcours est refusé pour un des composants du préfixe du chemin
pathname ou du nom d'un interpréteur de script (consultez aussi
path_resolution(7)).
EACCES Le fichier ou l'interpréteur de script n'est pas un fichier régulier.
EACCES L'autorisation d'exécution est refusée pour le fichier, ou un interpréteur de
script, ou un interpréteur ELF.
EACCES Le système de fichiers est monté avec l'option noexec.
EAGAIN (depuis Linux 3.1)
Ayant modifié son UID réel avec un des appels set*uid(), l’appelant était – et est
toujours — au-delà de sa limite de ressources RLIMIT_NPROC (consultez
setrlimit(2)). Pour une explication plus précise de cette erreur, consultez NOTES.
EFAULT pathname ou l'un des pointeurs du vecteur argv ou envp pointe en dehors de l'espace
d'adressage accessible.
EINVAL Un exécutable ELF a plusieurs segments PT_INTERP (indique plusieurs interpréteurs).
EIO Une erreur d'entrée-sortie s'est produite.
EISDIR L'interpréteur ELF cité est un répertoire.
ELIBBAD
L'interpréteur ELF mentionné n'est pas dans un format connu.
ELOOP Trop de liens symboliques rencontrés dans la résolution de pathname ou du nom de
l'interpréteur de script ou ELF.
ELOOP La limite maximale de niveaux a été atteinte pendant l'interprétation récursive du
script (voir « scripts interpréteurs » ci-dessus). Avant Linux 3.8, l'erreur
générée dans ce cas était ENOEXEC.
EMFILE La limite du nombre de descripteurs de fichiers par processus a été atteinte.
ENAMETOOLONG
nom_chemin est trop long.
ENFILE La limite du nombre total de fichiers ouverts pour le système entier a été
atteinte.
ENOENT Aucun fichier pathname ou interpréteur de script ou ELF n'existe.
ENOEXEC
Le fichier exécutable n'est pas dans le bon format, ou est destiné à une autre
architecture.
ENOMEM La mémoire disponible du noyau n'était pas suffisante.
ENOTDIR
Un composant du préfixe du chemin de pathname ou de l'interpréteur de script ou ELF
n'est pas un répertoire.
EPERM Le système de fichiers est monté avec l'attribut nosuid, l’utilisateur n’est pas le
superutilisateur et le fichier a un bit Set-UID ou Set-GID positionné.
EPERM Le processus est suivi avec ptrace(2), l'utilisateur n'est pas le superutilisateur,
et le fichier a un bit Set-UID ou Set-GID positionné.
EPERM Une application « capability-dumb » n'obtiendrait pas toutes les capacités rendues
possibles par le fichier exécutable. Voir capabilities(7).
ETXTBSY
L'exécutable spécifié était ouvert en écriture par un ou plusieurs processus.
CONFORMITÉ
POSIX.1-2001, POSIX.1-2008, SVr4, 4.3BSD. POSIX ne documente pas le comportement de « #! »
mais celui-ci existe (avec quelques variations) sur d'autres systèmes UNIX.
NOTES
On pourrait parfois voir execve() (et les fonctions associées décrites dans exec(3))
décrit comme un « exécuteur de nouveau processus » (ou équivalent). C'est une description
très trompeuse : il n'y a pas de nouveau processus ; beaucoup d'attributs du processus
appelant demeurent inchangés (en particulier son PID). Tout ce que fait execve() est de
s'organiser pour qu'un processus existant (le processus appelant) exécute un nouveau
programme.
Les processus Set-UID et Set-GID ne peuvent pas être suivis par ptrace(2).
Le résultat d'un montage de système de fichiers avec l'attribut nosuid peut varier suivant
les versions du noyau Linux : certaines refuseront l'exécution des fichiers Set-UID et
Set-GID lorsque cela donnerait à l'appelant des privilèges qu'il n'a pas (et renverront
l'erreur EPERM), d'autres ignoreront simplement les bits Set-UID et Set-GID mais
accepteront d'effectuer l'appel exec().
Sur Linux, argv et envp peuvent être indiqués comme NULL. Dans les deux cas, cela a le
même effet que de spécifier un argument comme un pointeur sur une liste contenant un seul
pointeur NULL. N'en profitez pas pour faire des choses non standard et non portables !.
Sur de nombreux autres systèmes UNIX, spécifier argv comme NULL donnera une erreur
(EFAULT). D'autres systèmes UNIX traitent le cas envp==NULL comme Linux.
POSIX.1 indique que les valeurs renvoyées par sysconf(3) ne doivent pas changer pendant la
vie d'un processus. Cependant, depuis Linux 2.6.23, si la limite de ressources
RLIMIT_STACK change, alors la valeur renvoyée par _SC_ARG_MAX changera également, pour
refléter le fait que la limite de l'espace qui reçoit les paramètres de la ligne de
commande et les variables d'environnement a changé.
Dans la plupart des cas où execve() échoue, le contrôle renvoie vers l’image exécutable
d’origine et l’appelant de execve() peut alors traiter l’erreur. Cependant, dans de
(rares) cas (typiquement provoqués par un épuisement de ressources), l’échec pourrait se
produire après le point de non-retour : l’image exécutable d’origine a été supprimée, mais
la nouvelle image n’a pas pu être construite complètement. Dans ces cas-là, le noyau tue
le processus avec un signal SIGSEGV (SIGKILL jusqu'à Linux 3.17).
Scripts
Le noyau impose une longueur maximale de texte après les caractères « #! » au début du
script ; les caractères au-delà de cette limite sont ignorés. Avant Linux 5.1, la limite
était de 127 caractères. Depuis Linux 5.1, elle est de 255 caractères.
La sémantique de l'argument-optionnel d'un script diffère selon les implémentations. Sous
Linux, la chaîne qui suit le nom de l'interpréteur est passée à l'interpréteur comme un
seul mot, et cette chaîne peut contenir des espaces. Cependant, le comportement est
différent sur d'autres systèmes. Certains utilisent la première espace comme fin de
l'argument-optionnel. Sur certains systèmes, un script peut avoir plusieurs arguments,
délimités par des espaces dans argument-optionnel.
Linux (comme la plupart des autres systèmes UNIX modernes) ignore les bits Set-UID et
Set-GID sur les scripts.
execve() et EAGAIN
Une explication plus détaillée de l’erreur EAGAIN qui peut se produire (depuis Linux 3.1)
en appelant execve() est comme suit.
L’erreur EAGAIN peut se produire quand un appel précédent de setuid(2), setreuid(2) ou
setresuid(2) a causé la modification de l’identifiant d’utilisateur réel du processus et
que cette modification a forcé le processus à dépasser sa limite de ressources
RLIMIT_NPROC (c’est-à-dire que le nombre de processus appartenant au nouvel UID réel
dépasse la limite de ressources). De Linux 2.6.0 à 3.0, cela provoquait un échec de
l’appel set*uid() (avant 2.6, la limite de ressources n’était pas imposée sur les
processus qui modifiaient leurs identifiants d’utilisateur).
Depuis Linux 3.1, le scénario précédemment décrit ne provoque plus un échec de l’appel
set*uid(), parce que cela avait trop souvent pour conséquence des trous de sécurité quand
les applications boguées ne vérifiaient pas l’état de retour et assumait que — si
l’appelant avait les droits du superutilisateur — l’appel réussirait toujours. À la place,
les appels set*uid() modifient vraiment l’UID réel, mais le noyau définit un attribut
interne, appelé PF_NPROC_EXCEEDED, pour noter que la limite de ressources RLIMIT_NPROC a
été dépassée. Si l’attribut PF_NPROC_EXCEEDED est défini et que la limite de ressources
est toujours dépassée au moment d’un appel execve() ultérieur, cet appel échoue avec
l’erreur EAGAIN. Cette logique du noyau assure que la limite de ressources RLIMIT_NPROC
est toujours respectée pour le mode de fonctionnement habituel du démon avec droits
— c’est-à-dire fork(2) + set*uid() + execve().
Si la limite de ressources n’était pas encore dépassée au moment de l’appel execve()
(parce que d’autres processus appartenant à cet UID réel se sont terminés entre l’appel
set*uid() et l’appel execve()), alors l’appel execve() réussit et le noyau efface
l’attribut de processus PF_NPROC_EXCEEDED. L’attribut est aussi effacé si un appel
ultérieur de fork(2) par ce processus réussit.
Historique
Avec UNIX V6, la liste des arguments d'un appel exec() se terminait par 0, alors que la
liste des arguments de main se terminait par -1. Aussi, cette liste d'arguments n'était
pas utilisable directement dans un appel exec() supplémentaire. Depuis UNIX V7, les deux
terminateurs sont NULL.
EXEMPLES
Le programme suivant est conçu pour être exécuté par le second programme ci‐dessous. Il se
contente d'afficher les paramètres de sa ligne de commande, un par ligne.
/* myecho.c */
#include <stdio.h>
#include <stdlib.h>
int
main(int argc, char *argv[])
{
for (int j = 0; j < argc; j++)
printf("argv[%d]: %s\n", j, argv[j]);
exit(EXIT_SUCCESS);
}
Ce programme peut être utilisé pour exécuter le programme donné comme argument de ligne de
commande :
/* execve.c */
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
int
main(int argc, char *argv[])
{
char *newargv[] = { NULL, "hello", "world", NULL };
char *newenviron[] = { NULL };
if (argc != 2) {
fprintf(stderr, "Utilisation : %s <fichier_à_exécuter>\n", argv[0]);
exit(EXIT_FAILURE);
}
newargv[0] = argv[1];
execve(argv[1], newargv, newenviron);
perror("execve"); /* execve() ne renvoie qu'en cas d'erreur */
exit(EXIT_FAILURE);
}
On peut utiliser le second programme pour exécuter le premier de la façon suivante :
$ cc myecho.c -o myecho
$ cc execve.c -o execve
$ ./execve ./myecho
argv[0]: ./myecho
argv[1]: hello
argv[2]: world
On peut aussi utiliser ces programmes pour montrer l'utilisation d'un interpréteur de
scripts. Pour ce faire, on crée un script dont l'« interpréteur » est notre programme
myecho :
$ cat > script
#!./myecho script-arg
^D
$ chmod +x script
On peut alors utiliser notre programme pour exécuter le script :
$ ./execve ./script
argv[0]: ./myecho
argv[1]: script-arg
argv[2]: ./script
argv[3]: hello
argv[4]: world
VOIR AUSSI
chmod(2), execveat(2), fork(2), get_robust_list(2), ptrace(2), exec(3), fexecve(3),
getopt(3), system(3), capabilities(7), credentials(7), environ(7), path_resolution(7),
ld.so(8)
COLOPHON
Cette page fait partie de la publication 5.10 du projet man-pages Linux. Une description
du projet et des instructions pour signaler des anomalies et la dernière version de cette
page peuvent être trouvées à l'adresse https://www.kernel.org/doc/man-pages/.
TRADUCTION
La traduction française de cette page de manuel a été créée par Christophe Blaess
<https://www.blaess.fr/christophe/>, Stéphan Rafin <stephan.rafin@laposte.net>, Thierry
Vignaud <tvignaud@mandriva.com>, François Micaux, Alain Portal <aportal@univ-montp2.fr>,
Jean-Philippe Guérard <fevrier@tigreraye.org>, Jean-Luc Coulon (f5ibh) <jean-
luc.coulon@wanadoo.fr>, Julien Cristau <jcristau@debian.org>, Thomas Huriaux
<thomas.huriaux@gmail.com>, Nicolas François <nicolas.francois@centraliens.net>, Florentin
Duneau <fduneau@gmail.com>, Simon Paillard <simon.paillard@resel.enst-bretagne.fr>, Denis
Barbier <barbier@debian.org>, David Prévot <david@tilapin.org> et Jean-Philippe MENGUAL
<jpmengual@debian.org>
Cette traduction est une documentation libre ; veuillez vous reporter à la GNU General
Public License version 3 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ concernant les
conditions de copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.
Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un
message à debian-l10n-french@lists.debian.org ⟨⟩.