Provided by: manpages-fr-dev_4.26.0-1_all bug

NOM

       execve - Exécuter un programme

BIBLIOTHÈQUE

       Bibliothèque C standard (libc, -lc)

SYNOPSIS

       #include <unistd.h>

       int execve(const char *pathname, char *const _Nullable argv[],
                  char *const _Nullable 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 et  un  tas  nouvellement
       initialisés, et des segments de données (initialisés et non 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 d’interpréteur » 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] sera un pointeur 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.

       Cette  page  de  manuel décrit l'appel système Linux en détail ; pour un aperçu de la nomenclature et des
       nombreuses variantes, souvent préférables et standardisées de cette fonction, fournies par la libc,  dont
       celles qui recherchent la variable d'environnement PATH, voir exec(3).

       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-user-ID sauvegardé ; de la même manière, le GID
       effectif est copié dans le set-group-ID sauvegardé. Ces copies ont lieu  après  toute  modification  d'ID
       effectif à cause des bits de permission set-user-ID et set-group-ID.

       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  »  peuvent
          entraîner  le  passage  du propriétaire des fichiers du répertoire /proc/pid du 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 set-user-ID ou  set-group-ID  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 de SECBIT_KEEP_CAPS 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 d’interpréteur
       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 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)).

       Avant  Linux  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  Linux  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 à Linux 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
       Linux  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 est  positionné  pour
       indiquer l'erreur.

ERREURS

       E2BIG  Le  nombre total d'octets dans l'environnement (envp) et la liste d'arguments sont trop longs, une
              chaîne d'argument ou d'environnement est trop longue ou le pathname complet  de  l'exécutable  est
              trop long. L'octet NULL terminal est compté comme faisant partie de la longueur de la chaîne.

       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-user-ID ou set-group-ID positionné.

       EPERM  Le  processus est suivi avec ptrace(2), l'utilisateur n'est pas le superutilisateur, et le fichier
              a un bit set-user-ID ou set-group-ID 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.

VERSIONS

       POSIX  ne  documente  pas  le  comportement de « #! » mais celui-ci existe (avec quelques variations) sur
       d'autres systèmes UNIX.

       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é.

   Scripts d’interpréteur
       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-user-ID et set-group-ID
       sur les scripts.

STANDARDS

       POSIX.1-2008.

HISTORIQUE

       POSIX.1-2001, SVr4, 4.3BSD.

       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.

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-user-ID et set-group-ID 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-user-ID et set-group-ID  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-user-ID et set-group-ID mais accepteront d'effectuer l'appel exec().

       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).

   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 à Linux 3.0, cela
       provoquait un échec de l’appel set*uid() (avant Linux 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.

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 (size_t j = 0; j < argc; j++)
                   printf("argv[%zu]: %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[])
           {
               static char *newargv[] = { NULL, "hello", "world", NULL };
               static char *newenviron[] = { NULL };

               if (argc != 2) {
                   fprintf(stderr, "Usage: %s <file-to-exec>\n", argv[0]);
                   exit(EXIT_FAILURE);
               }

               newargv[0] = argv[1];

               execve(argv[1], newargv, newenviron);
               perror("execve");   /* execve() ne s'interrompt 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),  getauxval(3),
       getopt(3), system(3), capabilities(7), credentials(7), environ(7), path_resolution(7), ld.so(8)

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 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.

Pages du manuel de Linux 6.9.1                    15 juin 2024                                         execve(2)