  PATH Mini-HowTo
  Esa Turtiainen (etu@dna.fi)
  Version 0.4, 15 Novembre 1997

  L'objectif de ce HOWTO est de traiter l'utilisation des variables
  d'environnement sous Unix, et en particulier de la variable PATH.
  Adaptation franaise par Mathieu Lafon (Mathieu.Lafon@insalien.org),
  ralise le 22 Octobre 1998.

  11..  IInnttrroodduuccttiioonn


  Ce document aborde les astuces et les problmes relatifs aux variables
  d'environnement sous Unix/Linux, et plus spcialement  la variable
  PATH.  PATH est une liste de rpertoires dans lesquels le systme
  recherche les commandes  excuter.  Ce document s'appuie sur la
  distribution Debian Linux 1.3.

  Remarque: Ce document est en phase de dveloppement (bta).  Vous
  pouvez m'envoyer vos commentaires ou vos corrections.

  Les commentaires sur la traduction sont  envoyer  Mathieu Lafon
  (Mathieu.Lafon@insalien.org).


  22..  DDrrooiittss dd''aauutteeuurr


  Cette documentation est libre, vous pouvez la redistribuer et/ou la
  modifier selon les termes de la Licence Publique Gnrale GNU publie
  par la Free Software Foundation (version 2 ou bien toute autre version
  ultrieure choisie par vous).

  Cette documentation est distribue car potentiellement utile, mais
  SANS AUCUNE GARANTIE, ni explicite ni implicite, y compris les
  garanties de commercialisation ou d'adaptation dans un but spcifique.
  Reportez-vous  la Licence Publique Gnrale GNU pour plus de dtails.

  Vous pouvez obtenir une copie de la Licence Publique Gnrale GNU en
  crivant  la Free Software Foundation, Inc., 675 Mass Ave, Cambridge,
  MA 02139, Etats-Unis.


  33..  GGnnrraalliittss


  Tous les processus sous Unix possdent un _e_n_v_i_r_o_n_n_e_m_e_n_t.  C'est une
  liste de variables contenant un nom et une valeur, les deux sous la
  forme de chanes (pouvant contenir la majorit des caractres).  Tous
  les processus Unix possdent un processus parent, celui qui les a
  crs. Les processus fils hritent de l'environnement de leurs
  parents.  Ils peuvent ensuite y faire quelques modifications avant de
  le passer  leurs propres processus fils.

  Une variable importante de l'environnement est la variable PATH qui se
  prsente sous la forme d'une liste de rpertoires spars par le
  caractre deux-points (':').  Ces rpertoires sont parcourus pour
  rechercher les commandes.  Si vous essayez de lancer la commande
  bidule, tous les rpertoires contenus dans PATH seront examins (dans
  l'ordre),  la recherche de l'excutable bidule (un fichier avec le
  bit excutable positionn).  Si un tel fichier est trouv, il sera
  excut.

  Dans ce document, j'utilise le terme de _c_o_m_m_a_n_d_e pour un programme
  excutable qui est appel sans indication de son chemin, utilisant
  donc le mcanisme de PATH.
  Sous Linux, mme les appels de bas niveau pour lancer des processus
  (la famille des exec) se basent sur la variable PATH pour trouver les
  excutables : vous pouvez donc utiliser le mcanisme de PATH n'importe
  o, o vous voulez excuter une commande.  Si un appel de exec reoit
  le nom d'un fichier qui ne contient pas de '/', il cherchera dans la
  variable d'environnement PATH.  Mme si cette variable n'existe pas,
  les rpertoires /bin et /usr/bin seront examins  la recherche de
  cette commande.

  Pour crer ou modifier l'environnement, on utilisera export avec sh ou
  setenv avec csh. Par exemple :

   sh:
       export PATH=/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:.

   csh:
       setenv PATH /usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:.


  Les programmes C peuvent utiliser la fonction setenv() pour modifier
  l'environnement. Perl, quand  lui, conserve l'environnement dans le
  tableau associatif %ENV, et vous pouvez donc modifier PATH avec :

      $ENV{PATH}="/bin"


  La commande env est le moyen le plus facile pour connatre les vari
  ables de l'environnement courant. Elle peut galement tre utilise
  pour les modifier.

  Pour trouver plus d'information sur les commandes d'accs 
  l'environnement, vous pouvez regarder les pages de manuel de environ,
  execl, setenv, le fichier info env, ainsi que la documentation des
  shells.

  Quand Linux dmarre, le premier processus a tre lanc est init. C'est
  un processus particulier car il n'a pas de parent.  De plus, il s'agit
  de l'anctre de tous les autres processus.  Son environnement restera
  celui des autres processus tant qu'ils ne le modifieront pas. La
  plupart le modifieront.

  Le programme init lance un groupe de processus spcifis dans le
  fichier /etc/inittab. Ces processus travaillent dans un environnement
  directement hrit de init. Ce sont d'habitude des processus comme
  getty, le programme qui crit 'login:'  l'cran. Si vous lancez une
  connexion PPP ici, vous devez savoir que vous travaillez avec
  l'environnement de init. L'initialisation du systme est souvent
  effectue par un script lanc  cet endroit.  Dans le cas de la Debian
  1.3, il s'agit de /etc/init.d/rc qui est charg de lancer  son tour,
  les scripts d'initialisation.

  Le systme comprend plusieurs dmons qui peuvent ou non utiliser
  l'environnement par dfaut. La plupart de ceux-ci sont lanc par les
  scripts d'initialisation et possdent donc l'environnement de init.

  Quand un utilisateur se connecte, l'environnement est modifi par les
  paramtres contenus dans les programmes, les scripts d'initialisation
  communs  tous, et ceux spcifiques  l'utilisateur.  C'est assez
  compliqu et la situation n'est pas compltement satisfaisante. En
  effet, le comportement est totalement diffrent suivant que
  l'utilisateur se connecte  partir du terminal texte, de XDM ou du
  rseau.




  44..  iinniitt


  init est le processus parent de tous les autres processus du systme.
  Ceux-ci hritent de son environnement et mme de sa variable PATH dans
  le rare cas o aucun autre PATH n'est indiqu.

  Le PATH de init est fix dans le code source du programme.  Il s'agit
  de :

      /usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin


  Notez qu'il ne contient pas le rpertoire /usr/local/bin.

  Tous les programmes qui sont lancs  partir de /etc/inittab
  travaillent avec l'environnement de init, et en particulier les
  scripts d'initialisation contenus dans /etc/init.d (dans le cas de la
  Debian 1.3).

  Tout ce qui est lanc par les scripts d'initialisation possde par
  dfaut l'environnement de init.  Par exemple, syslogd, kerneld, pppd
  (lorsqu'il est lanc au dmarrage), gpm, et ce qui est le plus
  important, lpd et inetd possdent l'environnement de init et ne le
  modifient pas.

  Un certain nombre de programmes sont lancs par les scripts de
  dmarrage mais avec une variable PATH explicitement fixe dans le
  script. Les exemples de tels programmes sont atd, sendmail, apache et
  squid.

  D'autre programmes, par exemple cron, sont lancs par les scripts mais
  modifient totalement la variable PATH.


  55..  CCoonnnneexxiioonn


  Sur un terminal texte, il y a le programme getty qui attend le login
  de l'utilisateur. Il est charg d'crire 'login:' et quelques autres
  messages.  Il travaille avec l'environnement de init. Lorsque
  l'utilisateur commence  se connecter au moyen de getty, ce dernier
  invoque le programme login.  Celui-ci installe alors l'environnement
  utilisateur et lance le shell.

  Le programme login fixe le PATH comme dfini dans le fichier
  /usr/include/paths.h.

  Il s'agit, pour les utilisateurs normaux (_PATH_DEFPATH) de :

      /usr/local/bin:/usr/bin:/bin:.


  Et pour root (_PATH_DEFPATH_ROOT) de :

      /sbin:/bin:/usr/sbin:/usr/bin


  Le PATH des utilisateurs normaux ne contient aucun rpertoires sbin.
  Cependant, il contient le rpertoire courant '.', qui est considr
  comme dangereux pour l'utilisateur root. Mme /usr/local/bin n'est pas
  disponible pour root.

  Le PATH obtenu lors du login est souvent modifi par l'initialisation
  du shell.  Cependant, il est possible d'utiliser d'autres programmes
  que des shells dans /etc/passwd. Par exemple, j'utilise la ligne
  suivante pour lancer PPP quand je me connecte avec le nom
  d'utilisateur etu-ppp. Dans ce cas, pppd possde exactement le PATH du
  login.

      etu-ppp:viYabVlxPwzDl:1000:1000:Esa Turtiainen, PPP:/:/usr/sbin/pppd




  66..  SShheellllss


  Les processus utilisateurs sont souvent des processus fils du shell
  indiqu pour cet utilisateur dans le fichier /etc/passwd.  Les
  fichiers d'initialisation de ces shells modifient souvent la variable
  PATH.

  Lors de la connexion, le nom du shell est prcd d'un '-'. Par
  exemple, dans le cas de bash, on aura -bash. Cela indique au shell
  qu'il est en prsence d'un login shell et qu'il doit dans ce cas
  excuter les fichiers d'initialisation spcifiques  la connexion.
  Dans le cas contraire, on aura une initialisation plus lgre.  De
  plus, le shell dtermine s'il est interactif ou non, c'est  dire si
  les commandes viennent d'un terminal (tty) ou d'un fichier.  Cela
  modifie galement l'importance de l'initialisation si bien qu'un shell
  non interactif et qui n'est pas lanc avec une connexion effectue
  vraiment trs peu d'initialisation (bash n'excute aucune
  initialisation dans ce cas l).


  66..11..  bbaasshh


  Pour un login shell normal, bash parcourt le fichier /etc/profile,
  commun  tous, o les variables d'environnement, dont PATH, peuvent
  tre fixes pour les utilisateurs de bash. Cependant, ce fichier n'est
  pas relu lorsque le systme se trouve face  un shell non interactif.
  Le cas le plus important est rsh, o la commande est excute sur la
  machine voisine : le fichier /etc/profile n'est pas lanc et le PATH
  provient du dmon de rsh.

  bash accepte les arguments -login et -i qui sont utiliss pour obtenir
  respectivement un login shell et/ou un shell interactif.

  L'utilisateur peut redfinir les paramtres contenus dans /etc/profile
  en crant un fichier ~/.bash_profile, ~/.bash_login ou ~/.profile. Il
  faut noter que seul le premier fichier sera excut mme si cela
  diffre des habitudes de csh. En particulier, ~/.bash_login ne sera
  pas forcement excut pour un login shell, car si ~/.bash_profile
  existe, ce dernier sera prioritaire.

  Si bash est lanc par sh (qui est un lien symbolique sur bash), il se
  comporte comme le Bourne shell original : il ne parcourt que les
  fichiers /etc/profile et ~/.profile et uniquement dans le cas d'un
  login shell.


  66..22..  ttccsshh


  Pour un login shell, tcsh excute dans l'ordre les fichiers suivants :


    /etc/csh.cshrc


    /etc/csh.login

    ~/.tcshrc

    ~/.cshrc    (si ~/.tcshrc n'existe pas)

    ~/.history

    ~/.login

    ~/.cshdirs

  AAtttteennttiioonn.. tcsh peut tre compil pour excuter les scripts de
  connexion (login) avant les scripts cshrc.

  Les shells non interactifs n'excutent que les scripts *cshrc. Les
  scripts *login peuvent tre utiliss pour ne fixer le PATH que lors
  d'une connexion.


  77..  MMooddiiffiieerr ll''iiddeennttiitt ddee ll''uuttiilliissaatteeuurr



  77..11..  ssuu


  La commande su sert  indiquer la nouvelle identit  utiliser (sous
  rserve de connatre le mot de passe), root tant la valeur par
  dfaut.

  Normalement, su lance un sous-shell avec la nouvelle identit. Avec
  l'argument '-' (plus rcemment -l ou --login), su lance le shell comme
  un login shell. Cependant, il n'utilise pas le programme login pour
  cela mais encore un autre PATH intgr au programme pour simuler le
  login (termes employs dans le code source). Il s'agit de :

  pour les utilisateurs normaux :

      /usr/local/bin:/usr/bin:/bin:/usr/bin/X11:.


  pour l'utilisateur root :

      /sbin:/bin:/usr/sbin:/usr/bin:/usr/bin/X11:/usr/local/sbin:/usr/local/bin


  su ralise galement quelques changements mineurs dans l'environ
  nement.


  77..22..  ssuuddoo


  Il y a un groupe de commandes qui permettent une utilisation plus sr
  des commandes du super utilisateur. Elles permettent un meilleur suivi
  (au sens o l'on garde une trace de chaque excution - NdT), des
  restrictions sur les utilisateurs et utilisent des mots de passe
  individuels.  La plus utilise est srement sudo.

      $ sudo env


  Cette commande excute env en tant que super utilisateur (si sudo est
  configur pour le permettre).

  La commande sudo a encore une autre approche en ce qui concerne la
  gestion du PATH. Elle modifie les rpertoires o chercher la commande
   excuter pour que le rpertoire courant soit toujours le dernier.
  Cependant, elle ne modifie pas la variable PATH, seulement quelques
  variables comme SUDO_USER.


  88..  SSeerrvveeuurrss


  La majorit des serveurs ne devrait pas lancer n'importe quelle sorte
  de processus. Pour des raisons de scurit, leur PATH doit donc tre
  minimal.

  La plus grosse exception est l'ensemble des services qui autorisent
  une connexion sur le systme  partir du rseau.  Cette section dcrit
  comment se trouve l'environnement dans ces cas prcis. En effet, une
  commande excut  distance avec rsh aura un PATH diffrent d'une
  commande excut avec ssh. De la mme faon, une connexion  l'aide de
  rlogin, telnet ou ssh est diffrente.


  88..11..  iinneettdd


  La plupart des serveurs ne possdent pas de processus charg
  d'attendre en permanence l'arrive d'une requte. Ce travail est
  laiss  un super serveur (Internet super server), appel inetd. Le
  programme inetd est  l'coute permanente du rseau et lance le
  serveur appropri en fonction du port sur lequel arrive la requte.
  Son comportement est dfini dans le fichier /etc/inetd.conf.

  inetd est dmarr par les scripts de dmarrage du systme. Il hrite
  donc du PATH de init.  Il ne le modifie pas et tous les serveurs
  lancs par inetd possdent donc le PATH de init. Un exemple de tel
  serveur est imapd, le serveur du protocole IMAP.

  D'autre exemples de processus lancs par inetd sont telnetd, rlogind,
  talkd, ftp, popd, certains serveurs http, etc...

  Souvent, l'utilisation de inetd est complique par l'utilisation du
  programme tcpd, charg de lancer le vritable serveur. C'est un
  programme qui effectue quelques vrifications du point de vue scurit
  avant de lancer le vritable serveur. Il ne touche pas au PATH
  (information non vrifie).


  88..22..  rrsshh


  Le dmon de rsh utilise le PATH dfini par _PATH_DEFPATH
  (/usr/include/path.h), c'est  dire, le mme que celui utilis par le
  programme login pour connecter les utilisateurs normaux.
  L'utilisateur root obtiendra le mme PATH que les autres.

  En ralit, rshd excute la commande dsire en se servant de la
  commande suivante :

      shell -c ligne_de_commande


  O shell n'est pas un login shell. Il est prfrable que tous les
  shells mentionns dans /etc/passwd prennent en compte l'option -c pour
  pouvoir leur envoyer ce genre de ligne de commande.


  88..33..  rrllooggiinn


  rlogin invoque login pour effectuer la procdure de connexion.  Si
  vous vous connectez avec rlogin, vous aurez le mme PATH qu'avec
  login. La plupart des autres faons de se connecter  un ordinateur
  sous Linux n'utilisent pas login. Notez la diffrence avec rsh.

  La commande de login utilise est de la forme :

      login -p -h nom_de_l_hote nom_d_utilisateur


  L'option -p conserve l'environnement  l'exception des variables HOME,
  PATH, SHELL, TERM, MAIL et LOGNAME. L'option -h indique le nom de
  l'ordinateur sur lequel doit se faire la connexion.


  88..44..  tteellnneett


  Le programme telnet est similaire  rlogin : il utilise le programme
  login et la ligne de commande utilise est de la mme forme.


  88..55..  sssshh


  ssh possde sa propre variable PATH,  laquelle il ajoute le
  rpertoire o se trouve ssh. Cela implique souvent que le rpertoire
  /usr/bin se retrouve en double :

      /usr/local/bin:/usr/bin:/bin:.:/usr/bin


  La variable PATH ne contient pas /usr/bin/X11 et le shell invoqu par
  ssh n'est pas un login shell. Ainsi, la commande

      ssh hote_distant xterm


  ne marchera pas et rien de ce qui est contenu dans /etc/profile ou
  /etc/csh.cshrc ne pourra changer cela.  Vous devrez toujours utiliser
  des chemins absolus, par exemple /usr/bin/X11/xterm.

  ssh cherche des variables d'environnement de la forme VARIABLE=VALEUR
  dans le fichier /etc/environment.  Malheureusement, cela provoque des
  problmes avec XFree86.


  99..  XXFFrreeee8866



  99..11..  XXDDMM


  XDM est la manire la plus courante pour se connecter  partir d'un
  terminal graphique. Mme s'il ressemble  login, il se comporte, en
  interne, d'une manire totalement diffrente.

  Les fichiers de configuration se trouvent dans le rpertoire
  /etc/X11/xdm et sont excuts pendant les diffrentes tapes de la
  connexion. Xstartup (et Xstartup_0 pour l'cran 0) contient les
  commandes  excuter juste aprs la connexion. Ces commandes sont
  lancs en tant que root.
  Le PATH qui est utilis pour les utilisateurs se trouve dans
  /etc/X11/xdm/xdm-config.  Ce sont les lignes :

  DisplayManager*userPath: /usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games
  DisplayManager*systemPath: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11


  C'est le PATH par dfaut pour les utilisateurs normaux (userPath), et
  pour l'utilisateur root (systemPath) respectivement. Il est trs
  important que le rpertoire /usr/bin/X11 soit accessible pour les
  utilisateurs sous X. En effet, si un utilisateur se connecte  une
  autre machine pour lancer une application X, il faut qu'il aie
  /usr/bin/X11 dans son PATH car la machine hte ne saura pas qu'il dis
  pose d'un terminal X.

  Aprs Xstartup, XDM lance /etc/X11/Xsession en tant qu'utilisateur
  final. La configuration locale est contenue dans le fichier
  /etc/environment qui est parcouru, s'il existe, par Xsession.
  Xsession tant excut par /bin/sh, /etc/environment doit donc tre un
  script sh.  Cela interfre avec ssh qui suppose que /etc/environment
  est un fichier qui ne contient que des lignes de la forme
  VARIABLE=VALEUR.


  99..22..  xxtteerrmm --llss


  Par dfaut, le PATH de toutes les commandes lancs  partir des menus
  du gestionnaire de fentre est celui hrit de XDM. Pour en utiliser
  un autre, il faut le dfinir explicitement. Pour lancer un terminal X
  avec un PATH "normal", on doit utiliser des options spciales.  Pour
  xterm, l'option -ls (login shell) doit tre utilis pour obtenir un
  login shell avec le PATH dfini dans les fichiers d'initialisation du
  shell en question.


  99..33..  MMeennuuss eett bboouuttoonnss dduu ggeessttiioonnnnaaiirree ddee ffeennttrree


  Le gestionnaire de fentre hrite de l'environnement de XDM.  Tous les
  programmes lancs par lui hritent donc de cet environnement.

  L'environnement du shell de l'utilisateur n'affecte pas les programmes
  qui sont lancs par les menus ou les boutons. Par exemple, si un
  programme est lanc par un xterm (xterm -ls), il possde
  l'environnement par dfaut du login shell, par contre s'il est lanc
  par un menu, il aura l'environnement du gestionnaire de fentre.


  1100..  CCoommmmaannddeess "" rreettaarrddeemmeenntt"" ccrroonn eett aatt



  1100..11..  ccrroonn


  C'est le programme cron qui excute priodiquement les commandes
  spcifies dans /etc/crontab et dans les crontabs des utilisateurs. La
  Debian 1.3 possde en plus un mcanisme pour excuter les commandes de
  /etc/cron.daily, /etc/cron.weekly et /etc/cron.monthly, respectivement
  tous les jours, toutes les semaines et tous les mois.

  cron est lanc par les scripts de dmarrage mais il change son PATH en
  une valeur assez trange :


         /usr/bin:/binn:/sbin:/bin:/usr/sbin:/usr/bin


  IILL SS''AAGGIITT SSUURREEMMEENNTT DD''UUNN BBOOGGUUEE DDAANNSS CCRROONN.. Il s'agit en fait du PATH de
  init (/usr/bin:/bin) qui est copi ici, mais sans le 0 terminal
  (chane en convention C - NdT)! Ce bogue n'existe pas sur tous les
  systmes.

  Dans la crontab, on peut dfinir un PATH spcifique pour l'excution
  des commandes.  Pour la Debian 1.3, il s'agit de :

      PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin


  De cette faon, le PATH de crond n'est jamais utilis dans les pro
  grammes utilisateurs. Tous les scripts de /etc/cron.* obtiennent par
  dfaut le PATH de la crontab. Celui ci est utilis mme si le pro
  gramme n'est pas excut en tant que root.


  1100..22..  aatt


  La commande at est utilise pour lancer un programme  une heure
  fixe.

  Le programme atd est lanc avec le PATH de init.  Cependant, les
  programmes sont toujours lancs avec l'environnement utilisateur grce
   sh.  Les spcificits de sh s'appliquent donc ici.  Reportez vous au
  chapitre sur bash.


  1111..  QQuueellqquueess eexxeemmpplleess



  1111..11..  mmaaggiiccffiilltteerr


  magicfilter est un outil standard permettant de manipuler les fichiers
   destination de l'imprimante. Il analyse le type du fichier 
  imprimer et lance un filtre appropri pour l'imprimer de la meilleure
  faon. Les scripts utiliss pour filtrer sont lancs par lpd, lui mme
  lanc par le script /etc/init.d/lpd lanc par init. Le PATH est donc
  identique  celui de init et ne contient donc pas /usr/bin/X11.

  Si vous voulez envoyer des fichier PDF (Portable Data Format) 
  magicfilter, vous pouvez utiliser /usr/bin/X11/xpdf.  Mais vous ne
  devez pas oublier d'indiquer le chemin absolu. Sinon, magicfilter ne
  trouvera pas xpdf. La plupart des programmes utiliss avec
  magicfilter, ne ncessitent pas forcement un chemin explicite car ils
  se trouvent souvent dans /bin ou /usr/bin.


  1111..22..  IImmpprreessssiioonn  ppaarrttiirr dd''aapppplliiccaattiioonnss XX


  Au cas o vous utilisez la variable d'environnement PRINTER pour
  slectionner l'imprimante  utiliser, vous devez savoir que dans
  certains cas, certaines applications X risquent de ne pas la
  connatre.

  Vous vous souvenez srement que si la session X a t lanc par XDM,
  le gestionnaire de fentre ne se sert pas de vos scripts de login.
  Toutes les applications X que vous lancez  partir d'un xterm
  possdent donc la variable PRINTER.  Par contre, la mme application
  lance  partir d'un menu ou d'un bouton ne possdera pas cette
  variable.

  Parfois, la variable PRINTER peut tre hrite  un niveau encore plus
  bas. Par exemple, une application auxiliaire de Netscape pourra
  connatre votre variable PRINTER mme si Netscape ne la connat pas.


  1122..  QQuueessttiioonnss ddee ssccuurriitt


  Le mcanisme de PATH est souvent un gros problme du point de vue
  scurit. Utiliser une erreur dans la dfinition du PATH est une
  manire frquente de pirater un systme. Il est facile pour un pirate
  de fabriquer des chevaux de Troie, s'il arrive  forcer root ou un
  autre utilisateur  excuter ses propres programmes.

  Une erreur frquente par le pass (?) tait de laisser le rpertoire
  courant '.' dans le PATH de l'utilisateur root.  Un pirate malveillant
  peut alors crer son propre programme 'ls' dans son rpertoire.
  Ensuite, si root fait :

      # cd ~pirate
      # ls


  il excute le programme du pirate...

  De la mme faon, cela s'applique  tous les programmes excuts par
  root. Aucun important dmon ne devrait excuter quoi que ce soit qui
  puisse tre modifi par un utilisateur. Dans certains systmes,
  /usr/local/bin peut contenir des programmes jugs moins sr, mais le
  rpertoire est retir du PATH de root.  Cependant, si on sait qu'un
  dmon excute bidule avec 'PATH=/usr/local/bin:...', il est possible
  de tromper le dmon en lui faisant excuter /usr/local/bin/bidule  la
  place de /bin/bidule. Dans ce cas, n'importe qui pouvant crire dans
  /usr/local/bin peut srement pirater le systme.

  Il est donc trs important de faire attention  l'ordre dans lequel
  les rpertoires sont placs dans le PATH.  Si /usr/local/bin se trouve
  avant /bin, il y a un risque. Alors que s'il se trouve aprs, il est
  impossible de lancer la commande modifie /usr/local/bin/bidule  la
  place de /bin/bidule.

  Sous Linux, vous devez vous souvenir que la recherche dans le PATH est
  fate dans tous les mcanismes d'appels du systme d'exploitation.
  N'importe o, o le chemin d'un excutable est donn, vous pouvez
  utiliser le nom de la commande seul qui sera alors cherche au moins
  dans /bin et /usr/bin, et vraisemblablement dans beaucoup d'autres
  endroits.


  1133..  CCoommmmeenntt rrssoouuddrree lleess pprroobbllmmeess ??


  La commande la plus simple pour avoir accs  l'environnement est
  /usr/bin/env.

  Il est egalement possible d'utiliser le rpertoire /proc pour trouver
  le PATH de n'importe quel programme. Vous devez d'abord connatre le
  numro de processus du programme. Utilisez la commande ps pour
  l'obtenir. Par exemple, si xterm est le processus numro 1088, vous
  pouvez voir son environnement avec :

      # more /proc/1088/environ

  Cela ne marche pas avec des processus comme xdm. Pour accder 
  l'environnement d'un processus du systme ou d'un autre utilisateur,
  vous devez tre root.

  Pour deboguer Netscape, vous pouvez crer le script suivant :

      $ cat > /tmp/test
      #!/bin/sh
      /usr/bin/env > /tmp/env
      ^d
      $ chmod +x /tmp/test


  Ensuite, arrangez vous pour que votre programme soit appel  la place
  d'une application auxiliaire, par exemple RealAudio (audio/x-pn-
  realaudio). Lorsque vous essayerez d'accder  un lien RealAudio
  (quelque chose comme http://www.realaudio.com/showcase), Netscape
  lancera votre programme factice et sauvera l'environnement dans
  /tmp/env.


  1144..  MMtthhooddeess ppoouurr qquuee ttoouuss lleess uuttiilliissaatteeuurrss aaiieenntt llee mmmmee PPAATTHH


  Le rglage le plus important est  faire dans les fichiers commun
  d'initialisation des logins shells : /etc/csh.login pour tcsh et
  /etc/profile pour bash.

  Ceux qui n'obtiennent pas le bon PATH  partir de ces fichiers sont :
  rsh, ssh, les lments des menus du gestionnaire de fentres sous X ne
  lanant pas explicitement de login shell, les commandes lancs 
  partir de inittab, les travaux de cron, les travaux des dmons comme
  magicfilter (lanc par lprd), les scripts CGI (WWW), etc...

  Si le PATH est fix dans /etc/csh.cshrc, il sera utilis si rsh ou ssh
  lance des commandes sur une machine distante o l'utilisateur utilise
  tcsh/csh. Par contre, il n'est pas possible de rgler le PATH si
  l'utilisateur utilise bash/sh. Voici une mthode pour ne garder le
  PATH que dans un seul fichier, par exemple /etc/environnement-commun,
  dans lequel on crit :

    ${EXPORT}PATH${EQ}/bin:/usr/bin:/sbin:/usr/sbin:/usr/bin/X11:/usr/local/bin:/usr/games:.


  On peut ensuite l'utiliser  partir de /etc/csh.login (pour tcsh et
  csh)

    set EQ=" " set EXPORT="setenv "; source /etc/environnement-commun


  A partir de /etc/profile (pour bash, mais pas pour le vrai sh)

    EQ='=' EXPORT="export " . /etc/environnement-commun


  Et  partir de /etc/environment (pour XDM)

    EQ='=' EXPORT="export " . /etc/environnement-commun



  Cette mthode marchera la plupart du temps, sauf que ssh se plaindra
  des lignes contenues dans /etc/environment (ainsi que des variables EQ
  et EXPORT). De plus, rsh n'aura toujours pas le bon PATH s'il passe
  par bash.

  1155..  RReemmeerrcciieemmeennttss


  Une des raisons pour commencer l'criture de ce document a t la
  grosse frustration de Ari Mujunen. Juha Takala m'a donn de prcieux
  commentaires.




























































