<!--
     The FreeBSD Documentation Project
     The FreeBSD French Documentation Project
         
     $Id: chapter.sgml,v 1.1 2002-02-14 14:25:02 gioria Exp $
     Original revision: 1.3
     $FreeBSD$

-->

    <chapter id="secure">
      <title>Programmation s&#233;curis&#233;e</title>

      <para>Ce chap&icirc;tre a &eacute;t&eacute; &eacute;crit par Murray Stokely.</para>

      <sect1><title>Synopsis</title>
 
      <para>Ce chap&icirc;tre d&eacute;crit quelques probl&egrave;mes de s&eacute;curit&eacute; qui
      ont tourment&eacute; les programmeurs Unix depuis des dizaines d'ann&eacute;es
      et quelques uns des nouveaux outils disponibles pour aider
      les programmeurs &agrave; &eacute;viter l'&eacute;criture de code non s&eacute;curis&eacute;.
      </para>
      </sect1>

      <sect1 id="secure-philosophy"><title>M&#233;thodologie de d&#233;veloppement
      s&#233;curis&#233;</title>

      <para>Ecrire des applications s&eacute;curis&eacute;es demande une tr&egrave;s minutieuse
      et pessimiste vision de la vie. Les applications devrait fonctionner
      avec le principe du <quote>privil&egrave;ge moindre</quote> de façon &agrave; ce 
      qu'aucun processus ne fonctionne avec plus que le strict minimum dont
      il a besoin pour accomplir sa t&acirc;che. Le code pr&eacute;-test&eacute; devrait &ecirc;tre
      r&eacute;utilis&eacute; autant que possible pour &eacute;viter les erreurs communes que
      d'autres peuvent d&eacute;j&agrave; avoir r&eacute;par&eacute;es.</para>

      <para>Un des pi&egrave;ges de l'environnement Unix est qu'il est facile
      d'affecter la stabilit&eacute; de l'environnement.
      Les applications ne devraient jamais avoir confiance dans la saisie
      de l'utilisateur (sous toutes ses formes),
      les ressources syst&egrave;me, la communication inter-processus, ou l'encha&icirc;nement
      des &eacute;v&egrave;nements. Les processus Unix n'ex&eacute;cutent pas de mani&egrave;re synchrone 
      aussi, logiquement, les op&eacute;rations sont rarement atomiques.</para>
      </sect1>

      <sect1><title>D&#233;passement de capacit&#233;</title> 

      <para>Les d&eacute;passements de capacit&eacute; ("Buffer Overflows") existent depuis
      les d&eacute;buts de l'architecture de Von-Neuman <xref linkend="COD">.
      Ils gagn&egrave;rent une grande notori&eacute;t&eacute; en 1988 avec le ver pour Internet
      de Morris. Malheureusement, la m&ecirc;me attaque basique reste effective
      aujourd'hui. Des 17 rapports de s&eacute;curit&eacute; du CERT de 1999, 10
      furent caus&eacute;s directement des bogues logiciels de d&eacute;passement de 
      capacit&eacute;. De loin la plus commune de types d'attaques par d&eacute;passement de
       capacit&eacute; est bas&eacute;e sur la corruption de la pile.</para>

      <para>La plupart des syst&egrave;mes informatiques modernes utilise une pile 
      pour passer les arguments aux proc&eacute;dures et stocker les variables locales
      Une pile est une zone m&eacute;moire dernier entr&eacute;-premier sorti (Last In-First
       Out : LIFO) dans la zone de m&eacute;moire haute de l'image d'un processus. 
      Quand un programme invoque une fonction une nouvelle structure pile est 
      cr&eacute;&eacute;e. Cette structure pile consiste dans les arguments pass&eacute;s &agrave; la 
      fonction aussi bien que dans une quantit&eacute; dynamique d'espace pour
      la variable locale. Le pointeur de pile est un registre qui r&eacute;f&eacute;rence la
      position courante du sommet de la pile. Etant donn&eacute; que cette valeur
      change constamment au fur et &agrave; mesure que de nouvelles valeurs sont 
      ajout&eacute;es au sommet de la pile, beaucoup d'impl&eacute;mentations fournissent
      aussi un pointeur de structure qui est positionn&eacute; dans le voisinage du
      d&eacute;but de la structure pile de façon &agrave; ce que les variables locales soient
      plus facilement adressables relativement &agrave; cette valeur.
      <xref linkend="COD"> L'adresse de retour des appels de fonction est aussi
      stock&eacute; dans la pile, et cela est la cause des d&eacute;couvertes des 
      d&eacute;passements de pile puisque faire d&eacute;border une variable locale dans une
      fonction peut &eacute;craser l'adresse de retour de cette fonction, permettant
      potentiellement &agrave; un utilisateur malveillant d'ex&eacute;cuter le code qu'il ou
      elle d&eacute;sire.</para>

      <para>Bien que les attaques bas&eacute;es sur les d&eacute;passements de pile soient 
      de loin les plus communes, il serait aussi possible de faire exploser
      la pile avec une attaque du tas (malloc/free).</para>

      <para>Le langage de programmation C ne r&eacute;alise pas de v&eacute;rifications
      automatiques des limites sur les tableaux ou pointeurs comme d'autres
      langages le font. De plus, la librairie standard du C est remplie d'une 
      poign&eacute;e de fonctions tr&egrave;s dangereuses.</para>

      <informaltable>
        <tgroup cols=2>
          <tbody>
          <row><entry><function>strcpy</function>(char *dest, const char
          *src)</entry>
          <entry><simpara>Peut faire d&eacute;border le tampon dest</simpara></entry>
          </row>

          <row><entry><function>strcat</function>(char *dest, const char
          *src)</entry>
          <entry><simpara>Peut faire d&eacute;border le tampon dest</simpara></entry>
          </row>

          <row><entry><function>getwd</function>(char *buf)</entry>
          <entry><simpara>Peut faire d&eacute;border le tampon buf</simpara></entry>
          </row>

          <row><entry><function>gets</function>(char *s)</entry>
          <entry><simpara>Peut faire d&eacute;border le tampon s</simpara></entry>
          </row>

          <row><entry><function>[vf]scanf</function>(const char *format,
          ...)</entry>
          <entry><simpara>Peut faire d&eacute;border ses arguments.</simpara></entry>
          </row>

          <row><entry><function>realpath</function>(char *path, char
          resolved_path[])</entry>
          <entry><simpara>Peut faire d&eacute;border le tampon path</simpara></entry>
          </row>

          <row><entry><function>[v]sprintf</function>(char *str, const char
          *format, ...)</entry>
          <entry><simpara>Peut faire d&eacute;border le tampon str.</simpara></entry>
          </row>
          </tbody>
        </tgroup>
      </informaltable>

      <sect2><title>Exemple de d&#233;passement de capacit&#233;</title>

      <para>L'exemple de code suivant contient un d&eacute;passement de capacit&eacute;
      conçu pour &eacute;craser l'adresse de retour et "sauter" l'instruction suivant
      imm&eacute;diatement l'appel de la fonction. (Inspir&eacute;
      par <xref linkend="Phrack">)</para>

<programlisting>#include <sgmltag>stdio.h</sgmltag>

void manipulate(char *buffer) {
  char newbuffer[80];
  strcpy(newbuffer,buffer);
}

int main() {
  char ch,buffer[4096];
  int i=0;

  while ((buffer[i++] = getchar()) != '\n') {};
  
  i=1;
  manipulate(buffer);
  i=2;
  printf("La valeur de i est : %d\n",i);
  return 0;
}</programlisting>

      <para>Examinons quel serait l'aspect de l'image m&eacute;moire de ce processus 
      si nous avions entr&eacute; 160 espaces dans notre petit programme avant 
      d'appuyer sur <keycap>Entr&eacute;e</keycap>.</para> 

      <para>[XXX Sch&eacute;ma ici!]</para>

      <para>Evidemment une entr&eacute;e plus malveillante pourrait &ecirc;tre imagin&eacute;e pour
      ex&eacute;cuter des instructions d&eacute;j&agrave; compil&eacute;es (comme exec(/bin/sh)).</para>
      </sect2>

      <sect2><title>Eviter les d&#233;passements de capacit&#233;</title>

      <para>La solution la plus simple au probl&egrave;me de d&eacute;bordement de pile
      est de toujours utiliser de la m&eacute;moire restreinte en taille et
      les fonctions de copie de cha&icirc;ne de caract&egrave;res. <function>strncpy</function>
      et <function>strncat</function> font parties de la libraire standard du 
      C. Ces fonctions acceptent une valeur de longueur comme param&egrave;tre qui
      qui ne devrait pas &ecirc;tre plus grande que la taille du tampon de 
      destination. Ces fonctions vont ensuite copier `taille' octets de la
      source vers la destination. Toutefois, il y a un certain nombre de 
      probl&egrave;mes avec ces fonctions. Aucune fonction ne garantit une terminaison
      par le caract&egrave;re NULL si la taille du tampon d'entr&eacute;e est aussi grand 
      que celui de destination. Le param&egrave;tre taille est aussi utilis&eacute; de façon
      illogique entre <function>strncpy</function> et <function>strncat</function>
      aussi il est facile pour les programmeurs d'&ecirc;tre d&eacute;rout&eacute;s sur leur
      utilisation convenable. Il y a aussi une perte significative des 
      performances compar&eacute; &agrave; <function>strcpy</function> lorsque l'on copie 
      une courte cha&icirc;ne dans un grand tampon puisque <function>strncpy</function> 
      remplit de caract&egrave;res NULL jusqu'&agrave; la taille sp&eacute;cifi&eacute;e.</para>

      <para>Dans OpenBSD, une autre impl&eacute;mentation de la copie de m&eacute;moire 
      a &eacute;t&eacute; cr&eacute;&eacute;e pour contourner ces probl&egrave;mes. Les fonctions <function>strlcpy</function>
      et <function>strlcat</function> garantissent qu'elles termineront 
      toujours le tampon de destination par un caract&egrave;re NULL losque l'argument
      de taille est diff&eacute;rent de z&eacute;ro. Pour plus d'informations sur ces 
      fonctions, voir <xref linkend="OpenBSD">. Les fonctions <function>strlcpy</function> et
      <function>strlcat</function> d'OpenBSD ont &eacute;t&eacute; inclues dans FreeBSD 
      depuis la version 3.5.</para>

        <sect3><title>V#233;rifications des limites en fonctionnement bas&eacute;es sur le compilateur</title>
        <!--Compiler based run-time bounds -->

        <para>Malheureusement il y a toujours un tr&egrave;s important assortiment de
        code en utilisation publique qui copie aveugl&eacute;ment la m&eacute;moire sans
        utiliser une des routines de copie limit&eacute;e dont nous venons juste de 
        discuter. Heureusement, il y a une autre solution.  Plusieurs produits
        compl&eacute;mentaires pour compilateur et librairies existent pour faire 
        de la v&eacute;rification de limites pendant le fonctionnement en C/C++.</para> 

        <para>StackGuard est un de ces produits qui est impl&eacute;ment&eacute; comme un 
        petit correctif ("patch") pour le g&eacute;n&eacute;rateur de code gcc. Extrait du 
        site Internet de StackGuard, http://immunix.org/stackguard.html :
        <blockquote><para>"StackGuard d&eacute;tecte et fait &eacute;chouer les attaques 
        par d&eacute;bordement de pile en emp&ecirc;chant l'adresse de retour sur la pile
        d'&ecirc;tre alt&eacute;r&eacute;e. StackGuard place un mot "canari" 
        <footnote><para>NDT : Jaune de pr&eacute;f&eacute;rence pour &ecirc;tre bien visible</para></footnote>
        &agrave; c&ocirc;t&eacute; de l'adresse de retour quand la fontion est appel&eacute;e. Si le mot
        "canari" a &eacute;t&eacute; alt&eacute;r&eacute; au retour de la fonction, alors une attaque par
        d&eacute;bordement de pile a &eacute;t&eacute; tent&eacute;e et le programme r&eacute;pond en envoyant
        une alerte d'intrusion dans la trace syst&egrave;me (syslog) et 
        s'arr&ecirc;te alors."</para></blockquote> 

        <blockquote><para>"StackGuard est impl&eacute;ment&eacute; comme un petit correctif
        au g&eacute;n&eacute;rateur de code gcc, sp&eacute;cifiquement sur les routines 
        function_prolog() et function_epilog().  function_prolog() a &eacute;t&eacute;
        am&eacute;lior&eacute; pour laisser des "canaris" sur la pile quand les fonctions
        d&eacute;marrent, et function_epilog v&eacute;rifie l'int&eacute;grit&eacute; des "canaris" quand
        la fonction se termine. Tout essai pour corrompre l'adresse de retour
        est alors d&eacute;tect&eacute;e avant que la fonction ne retourne."</para></blockquote>
        </para>

        <para>Recompiler votre application avec StackGuard est un
        moyen efficace pour stopper la plupart des attques par d&eacute;passement de 
        capacit&eacute;, mais cela peut toujours &ecirc;tre compromis.</para>

        </sect3>

        <sect3><title>V&#233;rifications des limites en fonctionnement bas&#233;es sur les librairies</title>

        <para>Les m&eacute;canismes bas&eacute;s sur le compilateur sont totalement inutiles 
        pour logiciel seulement binaire que vous ne pouvez recompiler. Pour
        ces situations, il existe un nombre de librairies qui re-impl&eacute;mente
        les fonctions peu sûres de la librairie C
        (<function>strcpy</function>, <function>fscanf</function>,
        <function>getwd</function>, etc..) et assurent que ces
        fonctions ne peuvent pas &eacute;crire plus loin que le pointeur de pile.</para>

        <itemizedlist>
        <listitem><simpara>libsafe</simpara></listitem>
        <listitem><simpara>libverify</simpara></listitem>
        <listitem><simpara>libparnoia</simpara></listitem>
        </itemizedlist>

	<para>Malheureusement ces d&eacute;fenses bas&eacute;es sur les librairies poss&egrave;dent
	un certain nombre de d&eacute;fauts. Ces librairies prot&egrave;gent seulement d'un
        tr&egrave;s petit ensemble de probl&egrave;mes li&eacute;s &agrave; la s&eacute;curit&eacute; et oublient de 
        r&eacute;parer le probl&egrave;me actuel. Ces d&eacute;fenses peuvent &eacute;chouer si 
        l'application a &eacute;t&eacute; compil&eacute;e avec -fomit-frame-pointer. De m&ecirc;me, les
        variables d'environnement LD_PRELOAD et LD_LIBRARY_PATH peuvent &ecirc;tre
        r&eacute;&eacute;crites/non d&eacute;finies par l'utilisateur.</para>
        </sect3>

        </sect2>
      </sect1>

      <sect1><title>Les probl&#232;mes li&#233;s &#224; SetUID</title>

      <para>Il y a au moins 6 differents ID (identifiants) associ&eacute;s &agrave; un 
      processus donn&eacute;. A cause de cela, vous devez &ecirc;tre tr&egrave;s attentif avec
      l'acc&egrave;s que votre processus poss&egrave;de &agrave; un instant donn&eacute;. En particulier,
      toutes les applications ayant reçu des privil&egrave;ges par seteuid doivent 
      les abandonn&eacute;s d&egrave;s qu'ils ne sont plus n&eacute;cessaires.</para>

      <para>L'identifiant de l'utilisateur r&eacute;el (real user ID) peut seulement
      &ecirc;tre chang&eacute; par un processus super-utilisateur. Le programme <application>login</application> 
      met celui &agrave; jour quand un utilisateur se connecte et il est rarement 
      chang&eacute;.</para>

      <para>L'identifiant de l'utilisateur effectif (effective user ID) est mis
      &agrave; jour par les fonctions <function>exec()</function> si un programme 
      poss&egrave;de son bit seteuid plac&eacute;. Une application peut appeler
      <function>seteuid()</function> &agrave; n'importe quel moment pour r&egrave;gler
      l'identifiant de l'utilisateur effectif sur l'identifiant d'un 
      utilisateur r&eacute;el ou sur le "set-user-ID" sauv&eacute;.
      Quand l'identifiant de l'utilisateur effectif est plac&eacute; par les 
      fonctions <function>exec()</function>, la valeur pr&eacute;c&eacute;dente est sauv&eacute;e 
      dans le "set-user-ID" sauv&eacute;.</para>

      </sect1>

      <sect1 id="chroot"><title>Limiter l'environnement de votre programme</title>

      <para>La m&eacute;thode traditionnelle pour restreindre l'acc&egrave;s d'un processus
      se fait avec l'appel syst&egrave;me <function>chroot()</function>. Cet appel
      syst&egrave;me change le r&eacute;pertoire racine depuis lequel tous les autres chemins
      sont r&eacute;f&eacute;renc&eacute;s pour un processus et ses fils. Pour que cet appel 
      r&eacute;ussisse, le processus doit avoir ex&eacute;cut&eacute; (recherch&eacute;)
      la permission dans le r&eacute;pertoire r&eacute;f&eacute;renc&eacute;. Le nouvel environnement
      environment ne prend pas effet que lorsque vous appelez <function>chdir()</function> 
      dans celui-ci. 
      Il doit &ecirc;tre aussi not&eacute; qu'un processus peut facilement s'&eacute;chapper
      d'un environnement chroot s'il a les privil&egrave;ges du super-utilisateur.
      Cela devrait &ecirc;tre accompli en cr&eacute;ant des fichiers sp&eacute;ciaux de 
      p&eacute;riph&eacute;rique pour la m&eacute;moire du noyau, en attachant un d&eacute;vermineur &agrave; un 
      processus depuis l'ext&eacute;rieur de sa "prison", ou par d'autres mani&egrave;res 
      cr&eacute;atrices.</para>
      
      <para>Le comportement de l'appel syst&egrave;me <function>chroot()</function>
      peut &ecirc;tre un peu contr&ocirc;l&eacute; avec la commande <command>sysctl</command> et 
      la variable kern.chroot_allow_open_directories. 
      Quand cette valeur est r&egrave;gl&eacute;e &agrave; 0, <function>chroot()</function> &eacute;chouera 
      avec EPERM s'il y a un r&eacute;pertoire d'ouvert. Si la variable est r&egrave;gl&eacute;e sur
      la valeur par d&eacute;faut 1, alors <function>chroot()</function> &eacute;chouera 
      avec EPERM s'il y a un r&eacute;pertoire d'ouvert et que le processus est d&eacute;j&agrave; 
      sujet &agrave; un appel <function>chroot()</function>. Pour toute autre valeur, la 
      v&eacute;rification des r&eacute;pertoires ouverts sera totalement court-circuit&eacute;e.</para>

      <sect2><title>La fonctionnalit&#233; "prison" de FreeBSD</title>

      <para>Le concept de Prison ("Jail") &eacute;tend
      <function>chroot()</function> en limitant les droits du
      super-utilisateur pour cr&eacute;er un v&eacute;ritable `serveur virtuel'. Une fois 
      qu'une prison est mise en place, toute communication r&eacute;seau doit avoir lieu 
      au travers de l'adresse IP sp&eacute;cifi&eacute;e, et le droit du 
      "privil&egrave;ge super-utilisateur" dans cette prison est s&eacute;v&egrave;rement g&ecirc;n&eacute;.</para>

      <para>Tant qu'il se trouve en prison, tout test avec les droits du 
      super-utilisateur dans le noyau au travers d'un appel &agrave; 
      <function>suser()</function> &eacute;chouera.
      Toutefois, quelques appels &agrave; <function>suser()</function> ont &eacute;t&eacute;
      chang&eacute;s par la nouvelle interface <function>suser_xxx()</function>.
      Cette fonction est responsable de fournir ou de retirer les acc&egrave;s
      aux droits du super-utilisateur pour les processus emprisonn&eacute;s.</para>

      <para>Un processus super-utilisateur dans un environnement emprisonn&eacute; 
      a le pouvoir de : </para>
      <itemizedlist>
      <listitem><simpara>Manipuler les identitifications avec
        <function>setuid</function>, <function>seteuid</function>,
        <function>setgid</function>, <function>setegid</function>,
        <function>setgroups</function>, <function>setreuid</function>,
        <function>setregid</function>, <function>setlogin</function></simpara></listitem>
      <listitem><simpara>R&egrave;gler les limites en ressources avec <function>setrlimit</function></simpara></listitem>
      <listitem><simpara>Modifier quelques variables du noyau par sysctl
        (kern.hostname)</simpara></listitem>
      <listitem><simpara><function>chroot()</function></simpara></listitem>
      <listitem><simpara>R&egrave;gler les param&egrave;tres d'un noeud virtuel (vnode):
        <function>chflags</function>,
        <function>fchflags</function></simpara></listitem>
      <listitem><simpara>R&egrave;gler les attributs d'un noeud virtuel comme 
      les permissions d'un fichier, le propri&eacute;taire, le groupe, la taille, 
      la date d'acc&egrave;s, et la date de modification.</simpara></listitem>
      <listitem><simpara>Se lier &agrave; des ports privil&eacute;gi&eacute;s sur Internet
        (ports < 1024)</simpara></listitem>
      </itemizedlist>

      <para><function>Jail</function> est un outil tr&egrave;s utile pour ex&eacute;cuter 
      des applications dans un environnement s&eacute;curis&eacute; mais il a des
      imperfections. Actuellement, les m&eacute;canismes IPC (Inter-Process 
      Communications) n'ont pas &eacute;t&eacute; convertis pour utiliser <function>suser_xxx</function>
      aussi des applications comme MySQL ne peuvent &ecirc;tre ex&eacute;cut&eacute;e dans une prison.
      L'acc&egrave;s super-utilisateur peut avoir un sens tr&egrave;s limit&eacute; dans une prison,
       mais il n'y aucune façon de sp&eacute;cifier exactement ce que tr&egrave;s limit&eacute;
      veut dire.</para>
      </sect2>

      <sect2><title>Les capacit&#232;s des processus POSIX.1e</title>

      <para>Posix a r&eacute;alis&eacute; un document de travail qui ajoute l'audit 
      d'&eacute;v&egrave;nement, les listes de contr&ocirc;le d'acc&egrave;s, les privil&egrave;ges fins,
      l'&eacute;tiquetage d'information, et le contr&ocirc;le d'acc&egrave;s mandat&eacute;.</para>
      <para>Il s'agit d'un travail en cours et c'est l'objectif du projet <ulink
      url="http://www.trustedbsd.org">TrustedBSD</ulink>. Une partie
      du travail initial a &eacute;t&eacute; int&eacute;gr&eacute; dans FreeBSD-current
      (cap_set_proc(3)).</para>

      </sect2>

      </sect1>

      <sect1><title>La confiance</title>

      <para>Une application ne devrait jamais supposer que tout est sain
      dans l'environnement des utilisateurs. Cela inclut (mais n'est 
      certainement pas limit&eacute; &agrave;) : la saisie de l'utilisateur, les signaux, 
      les variables d'environnement, les ressources, les communication 
      inter-processus, les mmaps, le r&eacute;pertoire de travail du syst&egrave;me de 
      fichiers, les descripteurs de fichier, le nombre de fichiers ouverts, 
      etc.</para>

      <para>Vous ne devriez jamais supposer que vous pouvez g&eacute;rer toutes les
      formes de saisie invalide qu'un utilisateur peut entrer. Votre 
      application devrait plut&ocirc;t utiliser un filtrage positif pour
      seulement permettre un sous-ensemble sp&eacute;cifique que vous jugez
      sain. Une mauvaise validation des entr&eacute;es a &eacute;t&eacute; la cause de beaucoup
      d&eacute;couvertes de bogues, sp&eacute;cialement avec les scripts CGI sur le web.
       Pour les noms de fichier, vous devez &ecirc;tre tout particuli&egrave;rement attentif
      aux chemins ("../", "/"), liens symboliques et caract&egrave;res d'&eacute;chappement
      de l'interpr&eacute;teur de commandes.</para>

      <para>Perl poss&egrave;de une caract&eacute;ristique t&egrave;s sympathique appel&eacute;e mode 
      "Taint" qui peut &ecirc;tre utilis&eacute;e pour emp&ecirc;cher les scripts d'utiliser
      des donn&eacute;es externes au programme par un moyen non sûr. Ce mode v&eacute;rifiera
      les arguments de la ligne de commandes, les variables d'environnement,
      les informations localis&eacute;es (propres aux pays), les r&eacute;sultats de certains
      appels syst&egrave;me (<function>readdir()</function>,
      <function>readlink()</function>,
      <function>getpwxxx()</function>) et toute entr&eacute;e de fichier.</para>

      </sect1>

      <sect1><title>Les conditions de course</title>

      <para>Une condition de course est un comportement anormal caus&eacute; par
      une d&eacute;pendance inattendue sur le s&eacute;quencement relatif des &eacute;v&egrave;nements. En
      d'autres mots, un programmeur a suppos&eacute; &agrave; tort qu'un &eacute;v&egrave;nement 
      particulier se passerait avant un autre.</para>

      <para>Quelques causes habituelles de conditions de course sont les 
      signaux, les v&eacute;rifications d'acc&egrave;s et les fichiers ouverts. 
      Les signaux sont des &eacute;v&egrave;nements asynchrones par nature aussi un soin
      particulier doit &ecirc;tre pris pour les utiliser.
      V&eacute;rifier les acc&egrave;s avec <function>access(2)</function> puis 
      <function>open(2)</function> n'est clairement pas atomique.
      Les utilisateurs peuvent d&eacute;placer des fichiers entre les deux appels.
      Les applications privil&eacute;gi&eacute;es devraient plut&ocirc;t faire un appel &agrave; 
      <function>seteuid()</function> puis appeler <function>open()</function> 
      directement. Dans le m&ecirc;me esprit, une application devrait toujours r&egrave;gler
      un umask correct avant un appel &agrave; <function>open()</function> pour 
      pr&eacute;venir le besoin d'appels non valides &agrave; <function>chmod()</function>.</para>

      </sect1>

     </chapter>
