This file is indexed.

/usr/share/doc/HOWTO/fr-html/Path.html is in doc-linux-fr-html 2013.01-3.

This file is owned by root:root, with mode 0o644.

The actual contents of the file can be viewed below.

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<meta name="generator" content=
"HTML Tidy for Linux (vers 25 March 2009), see www.w3.org">
<meta name="GENERATOR" content="LinuxDoc-Tools 0.9.71">
<title>PATH Mini-HowTo</title>
</head>
<body>
<h1>PATH Mini-HowTo</h1>
<h2>Esa Turtiainen (<code>etu@dna.fi</code>)</h2>
Version 0.4, 15 Novembre 1997
<hr>
<em>L'objectif de ce HOWTO est de traiter l'utilisation des
variables d'environnement sous Unix, et en particulier de la
variable PATH. Adaptation fran&ccedil;aise par Mathieu Lafon
(<code>Mathieu.Lafon@insalien.org</code>), r&eacute;alis&eacute;e
le 22 Octobre 1998.</em>
<hr>
<h2><a name="s1">1. Introduction</a></h2>
<p>Ce document aborde les astuces et les probl&egrave;mes relatifs
aux variables d'environnement sous Unix/Linux, et plus
sp&eacute;cialement &agrave; la variable PATH. PATH est une liste
de r&eacute;pertoires dans lesquels le syst&egrave;me recherche les
commandes &agrave; ex&eacute;cuter. Ce document s'appuie sur la
distribution Debian Linux 1.3.</p>
<p>Remarque: Ce document est en phase de d&eacute;veloppement
(b&ecirc;ta). Vous pouvez m'envoyer vos commentaires ou vos
corrections.</p>
<p>Les commentaires sur la traduction sont &agrave; envoyer
&agrave; Mathieu Lafon
(<code>Mathieu.Lafon@insalien.org</code>).</p>
<h2><a name="s2">2. Droits d'auteur</a></h2>
<p>Cette documentation est libre, vous pouvez la redistribuer et/ou
la modifier selon les termes de la Licence Publique
G&eacute;n&eacute;rale GNU publi&eacute;e par la Free Software
Foundation (version 2 ou bien toute autre version ult&eacute;rieure
choisie par vous).</p>
<p>Cette documentation est distribu&eacute;e car potentiellement
utile, mais SANS AUCUNE GARANTIE, ni explicite ni implicite, y
compris les garanties de commercialisation ou d'adaptation dans un
but sp&eacute;cifique. Reportez-vous &agrave; la Licence Publique
G&eacute;n&eacute;rale GNU pour plus de d&eacute;tails.</p>
<p>Vous pouvez obtenir une copie de la Licence Publique
G&eacute;n&eacute;rale GNU en &eacute;crivant &agrave; la Free
Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139,
Etats-Unis.</p>
<h2><a name="s3">3. G&eacute;n&eacute;ralit&eacute;s</a></h2>
<p>Tous les processus sous Unix poss&egrave;dent un
<em>environnement</em>. C'est une liste de variables contenant un
nom et une valeur, les deux sous la forme de cha&icirc;nes (pouvant
contenir la majorit&eacute; des caract&egrave;res). Tous les
processus Unix poss&egrave;dent un processus parent, celui qui les
a cr&eacute;&eacute;s. Les processus fils h&eacute;ritent de
l'environnement de leurs parents. Ils peuvent ensuite y faire
quelques modifications avant de le passer &agrave; leurs propres
processus fils.</p>
<p>Une variable importante de l'environnement est la variable PATH
qui se pr&eacute;sente sous la forme d'une liste de
r&eacute;pertoires s&eacute;par&eacute;s par le caract&egrave;re
deux-points (':'). Ces r&eacute;pertoires sont parcourus pour
rechercher les commandes. Si vous essayez de lancer la commande
<code>bidule</code>, tous les r&eacute;pertoires contenus dans PATH
seront examin&eacute;s (dans l'ordre), &agrave; la recherche de
l'ex&eacute;cutable <code>bidule</code> (un fichier avec le bit
ex&eacute;cutable positionn&eacute;). Si un tel fichier est
trouv&eacute;, il sera ex&eacute;cut&eacute;.</p>
<p>Dans ce document, j'utilise le terme de <em>commande</em> pour
un programme ex&eacute;cutable qui est appel&eacute; sans
indication de son chemin, utilisant donc le m&eacute;canisme de
PATH.</p>
<p>Sous Linux, m&ecirc;me les appels de bas niveau pour lancer des
processus (la famille des <code>exec</code>) se basent sur la
variable PATH pour trouver les ex&eacute;cutables&nbsp;: vous
pouvez donc utiliser le m&eacute;canisme de PATH n'importe
o&ugrave;, o&ugrave; vous voulez ex&eacute;cuter une commande. Si
un appel de <code>exec</code> re&ccedil;oit le nom d'un fichier qui
ne contient pas de '/', il cherchera dans la variable
d'environnement PATH. M&ecirc;me si cette variable n'existe pas,
les r&eacute;pertoires <code>/bin</code> et <code>/usr/bin</code>
seront examin&eacute;s &agrave; la recherche de cette commande.</p>
<p>Pour cr&eacute;er ou modifier l'environnement, on utilisera
<code>export</code> avec <code>sh</code> ou <code>setenv</code>
avec <code>csh</code>. Par exemple&nbsp;:</p>
<pre>
 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:.
</pre>
Les programmes C peuvent utiliser la fonction <code>setenv()</code>
pour modifier l'environnement. Perl, quand &agrave; lui, conserve
l'environnement dans le tableau associatif %ENV, et vous pouvez
donc modifier PATH avec&nbsp;:
<pre>
    $ENV{PATH}="/bin"
</pre>
La commande <code>env</code> est le moyen le plus facile pour
conna&icirc;tre les variables de l'environnement courant. Elle peut
&eacute;galement &ecirc;tre utilis&eacute;e pour les modifier.
<p>Pour trouver plus d'information sur les commandes d'acc&egrave;s
&agrave; l'environnement, vous pouvez regarder les pages de manuel
de <code>environ</code>, <code>execl</code>, <code>setenv</code>,
le fichier info <code>env</code>, ainsi que la documentation des
shells.</p>
<p>Quand Linux d&eacute;marre, le premier processus a &ecirc;tre
lanc&eacute; est <code>init</code>. C'est un processus particulier
car il n'a pas de parent. De plus, il s'agit de l'anc&ecirc;tre de
tous les autres processus. Son environnement restera celui des
autres processus tant qu'ils ne le modifieront pas. La plupart le
modifieront.</p>
<p>Le programme init lance un groupe de processus
sp&eacute;cifi&eacute;s dans le fichier <code>/etc/inittab</code>.
Ces processus travaillent dans un environnement directement
h&eacute;rit&eacute; de <code>init</code>. Ce sont d'habitude des
processus comme <code>getty</code>, le programme qui &eacute;crit
'login:' &agrave; l'&eacute;cran. Si vous lancez une connexion PPP
ici, vous devez savoir que vous travaillez avec l'environnement de
init. L'initialisation du syst&egrave;me est souvent
effectu&eacute;e par un script lanc&eacute; &agrave; cet endroit.
Dans le cas de la Debian 1.3, il s'agit de
<code>/etc/init.d/rc</code> qui est charg&eacute; de lancer
&agrave; son tour, les scripts d'initialisation.</p>
<p>Le syst&egrave;me comprend plusieurs d&eacute;mons qui peuvent
ou non utiliser l'environnement par d&eacute;faut. La plupart de
ceux-ci sont lanc&eacute; par les scripts d'initialisation et
poss&egrave;dent donc l'environnement de init.</p>
<p>Quand un utilisateur se connecte, l'environnement est
modifi&eacute; par les param&egrave;tres contenus dans les
programmes, les scripts d'initialisation communs &agrave; tous, et
ceux sp&eacute;cifiques &agrave; l'utilisateur. C'est assez
compliqu&eacute; et la situation n'est pas compl&egrave;tement
satisfaisante. En effet, le comportement est totalement
diff&eacute;rent suivant que l'utilisateur se connecte &agrave;
partir du terminal texte, de <code>XDM</code> ou du
r&eacute;seau.</p>
<h2><a name="s4">4. init</a></h2>
<p><code>init</code> est le processus parent de tous les autres
processus du syst&egrave;me. Ceux-ci h&eacute;ritent de son
environnement et m&ecirc;me de sa variable PATH dans le rare cas
o&ugrave; aucun autre PATH n'est indiqu&eacute;.</p>
<p>Le PATH de init est fix&eacute; dans le code source du
programme. Il s'agit de&nbsp;:</p>
<pre>
    /usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin
</pre>
Notez qu'il ne contient pas le r&eacute;pertoire
<code>/usr/local/bin</code>.
<p>Tous les programmes qui sont lanc&eacute;s &agrave; partir de
<code>/etc/inittab</code> travaillent avec l'environnement de
<code>init</code>, et en particulier les scripts d'initialisation
contenus dans <code>/etc/init.d</code> (dans le cas de la Debian
1.3).</p>
<p>Tout ce qui est lanc&eacute; par les scripts d'initialisation
poss&egrave;de par d&eacute;faut l'environnement de
<code>init</code>. Par exemple, <code>syslogd</code>,
<code>kerneld</code>, <code>pppd</code> (lorsqu'il est lanc&eacute;
au d&eacute;marrage), <code>gpm</code>, et ce qui est le plus
important, <code>lpd</code> et <code>inetd</code> poss&egrave;dent
l'environnement de <code>init</code> et ne le modifient pas.</p>
<p>Un certain nombre de programmes sont lanc&eacute;s par les
scripts de d&eacute;marrage mais avec une variable PATH
explicitement fix&eacute;e dans le script. Les exemples de tels
programmes sont <code>atd</code>, <code>sendmail</code>,
<code>apache</code> et <code>squid</code>.</p>
<p>D'autre programmes, par exemple <code>cron</code>, sont
lanc&eacute;s par les scripts mais modifient totalement la variable
PATH.</p>
<h2><a name="s5">5. Connexion</a></h2>
<p>Sur un terminal texte, il y a le programme <code>getty</code>
qui attend le login de l'utilisateur. Il est charg&eacute;
d'&eacute;crire 'login:' et quelques autres messages. Il travaille
avec l'environnement de <code>init</code>. Lorsque l'utilisateur
commence &agrave; se connecter au moyen de <code>getty</code>, ce
dernier invoque le programme <code>login</code>. Celui-ci installe
alors l'environnement utilisateur et lance le shell.</p>
<p>Le programme login fixe le PATH comme d&eacute;fini dans le
fichier <code>/usr/include/paths.h</code>.</p>
<p>Il s'agit, pour les utilisateurs normaux (_PATH_DEFPATH)
de&nbsp;:</p>
<pre>
    /usr/local/bin:/usr/bin:/bin:.
</pre>
Et pour root (_PATH_DEFPATH_ROOT) de&nbsp;:
<pre>
    /sbin:/bin:/usr/sbin:/usr/bin
</pre>
Le PATH des utilisateurs normaux ne contient aucun
r&eacute;pertoires <code>sbin</code>. Cependant, il contient le
r&eacute;pertoire courant '.', qui est consid&eacute;r&eacute;
comme dangereux pour l'utilisateur root. M&ecirc;me
<code>/usr/local/bin</code> n'est pas disponible pour root.
<p>Le PATH obtenu lors du login est souvent modifi&eacute; par
l'initialisation du shell. Cependant, il est possible d'utiliser
d'autres programmes que des shells dans <code>/etc/passwd</code>.
Par exemple, j'utilise la ligne suivante pour lancer PPP quand je
me connecte avec le nom d'utilisateur etu-ppp. Dans ce cas,
<code>pppd</code> poss&egrave;de exactement le PATH du login.</p>
<pre>
    etu-ppp:viYabVlxPwzDl:1000:1000:Esa Turtiainen, PPP:/:/usr/sbin/pppd
</pre>
<h2><a name="s6">6. Shells</a></h2>
<p>Les processus utilisateurs sont souvent des processus fils du
shell indiqu&eacute; pour cet utilisateur dans le fichier
<code>/etc/passwd</code>. Les fichiers d'initialisation de ces
shells modifient souvent la variable PATH.</p>
<p>Lors de la connexion, le nom du shell est
pr&eacute;c&eacute;d&eacute; d'un '-'. Par exemple, dans le cas de
<code>bash</code>, on aura <code>-bash</code>. Cela indique au
shell qu'il est en pr&eacute;sence d'un login shell et qu'il doit
dans ce cas ex&eacute;cuter les fichiers d'initialisation
sp&eacute;cifiques &agrave; la connexion. Dans le cas contraire, on
aura une initialisation plus l&eacute;g&egrave;re. De plus, le
shell d&eacute;termine s'il est interactif ou non, c'est &agrave;
dire si les commandes viennent d'un terminal (tty) ou d'un fichier.
Cela modifie &eacute;galement l'importance de l'initialisation si
bien qu'un shell non interactif et qui n'est pas lanc&eacute; avec
une connexion effectue vraiment tr&egrave;s peu d'initialisation
(<code>bash</code> n'ex&eacute;cute aucune initialisation dans ce
cas l&agrave;).</p>
<h2><a name="ss6.1">6.1 bash</a></h2>
<p>Pour un login shell normal, <code>bash</code> parcourt le
fichier <code>/etc/profile</code>, commun &agrave; tous, o&ugrave;
les variables d'environnement, dont PATH, peuvent &ecirc;tre
fix&eacute;es pour les utilisateurs de <code>bash</code>.
Cependant, ce fichier n'est pas relu lorsque le syst&egrave;me se
trouve face &agrave; un shell non interactif. Le cas le plus
important est <code>rsh</code>, o&ugrave; la commande est
ex&eacute;cut&eacute;e sur la machine voisine&nbsp;: le fichier
<code>/etc/profile</code> n'est pas lanc&eacute; et le PATH
provient du d&eacute;mon de <code>rsh</code>.</p>
<p><code>bash</code> accepte les arguments <code>-login</code> et
<code>-i</code> qui sont utilis&eacute;s pour obtenir
respectivement un login shell et/ou un shell interactif.</p>
<p>L'utilisateur peut red&eacute;finir les param&egrave;tres
contenus dans <code>/etc/profile</code> en cr&eacute;ant un fichier
<code>~/.bash_profile</code>, <code>~/.bash_login</code> ou
<code>~/.profile</code>. Il faut noter que seul le premier fichier
sera ex&eacute;cut&eacute; m&ecirc;me si cela diff&egrave;re des
habitudes de <code>csh</code>. En particulier,
<code>~/.bash_login</code> ne sera pas forcement
ex&eacute;cut&eacute; pour un login shell, car si
<code>~/.bash_profile</code> existe, ce dernier sera
prioritaire.</p>
<p>Si <code>bash</code> est lanc&eacute; par <code>sh</code> (qui
est un lien symbolique sur <code>bash</code>), il se comporte comme
le Bourne shell original&nbsp;: il ne parcourt que les fichiers
<code>/etc/profile</code> et <code>~/.profile</code> et uniquement
dans le cas d'un login shell.</p>
<h2><a name="ss6.2">6.2 tcsh</a></h2>
<p>Pour un login shell, <code>tcsh</code> ex&eacute;cute dans
l'ordre les fichiers suivants&nbsp;:</p>
<ul>
<li><code>/etc/csh.cshrc</code></li>
<li><code>/etc/csh.login</code></li>
<li><code>~/.tcshrc</code></li>
<li><code>~/.cshrc</code> (si <code>~/.tcshrc</code> n'existe
pas)</li>
<li><code>~/.history</code></li>
<li><code>~/.login</code></li>
<li><code>~/.cshdirs</code></li>
</ul>
<p><b>Attention.</b> <code>tcsh</code> peut &ecirc;tre
compil&eacute; pour ex&eacute;cuter les scripts de connexion
(<code>login</code>) avant les scripts <code>cshrc</code>.</p>
<p>Les shells non interactifs n'ex&eacute;cutent que les scripts
<code>*cshrc</code>. Les scripts <code>*login</code> peuvent
&ecirc;tre utilis&eacute;s pour ne fixer le PATH que lors d'une
connexion.</p>
<h2><a name="s7">7. Modifier l'identit&eacute; de
l'utilisateur</a></h2>
<h2><a name="ss7.1">7.1 su</a></h2>
<p>La commande <code>su</code> sert &agrave; indiquer la nouvelle
identit&eacute; &agrave; utiliser (sous r&eacute;serve de
conna&icirc;tre le mot de passe), root &eacute;tant la valeur par
d&eacute;faut.</p>
<p>Normalement, <code>su</code> lance un sous-shell avec la
nouvelle identit&eacute;. Avec l'argument '-' (plus
r&eacute;cemment <code>-l</code> ou <code>--login</code>),
<code>su</code> lance le shell comme un login shell. Cependant, il
n'utilise pas le programme <code>login</code> pour cela mais encore
un autre PATH int&eacute;gr&eacute; au programme pour simuler le
login (termes employ&eacute;s dans le code source). Il s'agit
de&nbsp;:</p>
<p>pour les utilisateurs normaux&nbsp;:</p>
<pre>
    /usr/local/bin:/usr/bin:/bin:/usr/bin/X11:.
</pre>
pour l'utilisateur root&nbsp;:
<pre>
    /sbin:/bin:/usr/sbin:/usr/bin:/usr/bin/X11:/usr/local/sbin:/usr/local/bin
</pre>
<code>su</code> r&eacute;alise &eacute;galement quelques
changements mineurs dans l'environnement.
<h2><a name="ss7.2">7.2 sudo</a></h2>
<p>Il y a un groupe de commandes qui permettent une utilisation
plus s&ucirc;r des commandes du super utilisateur. Elles permettent
un meilleur suivi (au sens o&ugrave; l'on garde une trace de chaque
ex&eacute;cution - NdT), des restrictions sur les utilisateurs et
utilisent des mots de passe individuels. La plus utilis&eacute;e
est s&ucirc;rement <code>sudo</code>.</p>
<pre>
    $ sudo env
</pre>
Cette commande ex&eacute;cute <code>env</code> en tant que super
utilisateur (si <code>sudo</code> est configur&eacute; pour le
permettre).
<p>La commande <code>sudo</code> a encore une autre approche en ce
qui concerne la gestion du PATH. Elle modifie les
r&eacute;pertoires o&ugrave; chercher la commande &agrave;
ex&eacute;cuter pour que le r&eacute;pertoire courant soit toujours
le dernier. Cependant, elle ne modifie pas la variable PATH,
seulement quelques variables comme SUDO_USER.</p>
<h2><a name="s8">8. Serveurs</a></h2>
<p>La majorit&eacute; des serveurs ne devrait pas lancer n'importe
quelle sorte de processus. Pour des raisons de
s&eacute;curit&eacute;, leur PATH doit donc &ecirc;tre minimal.</p>
<p>La plus grosse exception est l'ensemble des services qui
autorisent une connexion sur le syst&egrave;me &agrave; partir du
r&eacute;seau. Cette section d&eacute;crit comment se trouve
l'environnement dans ces cas pr&eacute;cis. En effet, une commande
ex&eacute;cut&eacute; &agrave; distance avec <code>rsh</code> aura
un PATH diff&eacute;rent d'une commande ex&eacute;cut&eacute; avec
<code>ssh</code>. De la m&ecirc;me fa&ccedil;on, une connexion
&agrave; l'aide de <code>rlogin</code>, <code>telnet</code> ou
<code>ssh</code> est diff&eacute;rente.</p>
<h2><a name="ss8.1">8.1 inetd</a></h2>
<p>La plupart des serveurs ne poss&egrave;dent pas de processus
charg&eacute; d'attendre en permanence l'arriv&eacute;e d'une
requ&ecirc;te. Ce travail est laiss&eacute; &agrave; un super
serveur (Internet super server), appel&eacute; <code>inetd</code>.
Le programme <code>inetd</code> est &agrave; l'&eacute;coute
permanente du r&eacute;seau et lance le serveur appropri&eacute; en
fonction du port sur lequel arrive la requ&ecirc;te. Son
comportement est d&eacute;fini dans le fichier
<code>/etc/inetd.conf</code>.</p>
<p><code>inetd</code> est d&eacute;marr&eacute; par les scripts de
d&eacute;marrage du syst&egrave;me. Il h&eacute;rite donc du PATH
de <code>init</code>. Il ne le modifie pas et tous les serveurs
lanc&eacute;s par <code>inetd</code> poss&egrave;dent donc le PATH
de <code>init</code>. Un exemple de tel serveur est
<code>imapd</code>, le serveur du protocole IMAP.</p>
<p>D'autre exemples de processus lanc&eacute;s par
<code>inetd</code> sont <code>telnetd</code>, <code>rlogind</code>,
<code>talkd</code>, <code>ftp</code>, <code>popd</code>, certains
serveurs http, etc...</p>
<p>Souvent, l'utilisation de <code>inetd</code> est
compliqu&eacute;e par l'utilisation du programme tcpd,
charg&eacute; de lancer le v&eacute;ritable serveur. C'est un
programme qui effectue quelques v&eacute;rifications du point de
vue s&eacute;curit&eacute; avant de lancer le v&eacute;ritable
serveur. Il ne touche pas au PATH (information non
v&eacute;rifi&eacute;e).</p>
<h2><a name="ss8.2">8.2 rsh</a></h2>
<p>Le d&eacute;mon de <code>rsh</code> utilise le PATH
d&eacute;fini par _PATH_DEFPATH (<code>/usr/include/path.h</code>),
c'est &agrave; dire, le m&ecirc;me que celui utilis&eacute; par le
programme <code>login</code> pour connecter les utilisateurs
normaux. L'utilisateur root obtiendra le m&ecirc;me PATH que les
autres.</p>
<p>En r&eacute;alit&eacute;, <code>rshd</code> ex&eacute;cute la
commande d&eacute;sir&eacute;e en se servant de la commande
suivante&nbsp;:</p>
<pre>
    shell -c ligne_de_commande
</pre>
O&ugrave; <code>shell</code> n'est pas un login shell. Il est
pr&eacute;f&eacute;rable que tous les shells mentionn&eacute;s dans
<code>/etc/passwd</code> prennent en compte l'option
<code>-c</code> pour pouvoir leur envoyer ce genre de ligne de
commande.
<h2><a name="ss8.3">8.3 rlogin</a></h2>
<p><code>rlogin</code> invoque login pour effectuer la
proc&eacute;dure de connexion. Si vous vous connectez avec
<code>rlogin</code>, vous aurez le m&ecirc;me PATH qu'avec
<code>login</code>. La plupart des autres fa&ccedil;ons de se
connecter &agrave; un ordinateur sous Linux n'utilisent pas
<code>login</code>. Notez la diff&eacute;rence avec
<code>rsh</code>.</p>
<p>La commande de <code>login</code> utilis&eacute;e est de la
forme&nbsp;:</p>
<pre>
    login -p -h nom_de_l_hote nom_d_utilisateur
</pre>
L'option <code>-p</code> conserve l'environnement &agrave;
l'exception des variables HOME, PATH, SHELL, TERM, MAIL et LOGNAME.
L'option <code>-h</code> indique le nom de l'ordinateur sur lequel
doit se faire la connexion.
<h2><a name="ss8.4">8.4 telnet</a></h2>
<p>Le programme <code>telnet</code> est similaire &agrave;
<code>rlogin</code>&nbsp;: il utilise le programme
<code>login</code> et la ligne de commande utilis&eacute;e est de
la m&ecirc;me forme.</p>
<h2><a name="ss8.5">8.5 ssh</a></h2>
<p><code>ssh</code> poss&egrave;de sa propre variable PATH,
&agrave; laquelle il ajoute le r&eacute;pertoire o&ugrave; se
trouve <code>ssh</code>. Cela implique souvent que le
r&eacute;pertoire <code>/usr/bin</code> se retrouve en
double&nbsp;:</p>
<pre>
    /usr/local/bin:/usr/bin:/bin:.:/usr/bin
</pre>
La variable PATH ne contient pas <code>/usr/bin/X11</code> et le
shell invoqu&eacute; par <code>ssh</code> n'est pas un login shell.
Ainsi, la commande
<pre>
    ssh hote_distant xterm
</pre>
ne marchera pas et rien de ce qui est contenu dans
<code>/etc/profile</code> ou <code>/etc/csh.cshrc</code> ne pourra
changer cela. Vous devrez toujours utiliser des chemins absolus,
par exemple <code>/usr/bin/X11/xterm</code>.
<p><code>ssh</code> cherche des variables d'environnement de la
forme VARIABLE=VALEUR dans le fichier
<code>/etc/environment</code>. Malheureusement, cela provoque des
probl&egrave;mes avec XFree86.</p>
<h2><a name="s9">9. XFree86</a></h2>
<h2><a name="ss9.1">9.1 XDM</a></h2>
<p>XDM est la mani&egrave;re la plus courante pour se connecter
&agrave; partir d'un terminal graphique. M&ecirc;me s'il ressemble
&agrave; <code>login</code>, il se comporte, en interne, d'une
mani&egrave;re totalement diff&eacute;rente.</p>
<p>Les fichiers de configuration se trouvent dans le
r&eacute;pertoire <code>/etc/X11/xdm</code> et sont
ex&eacute;cut&eacute;s pendant les diff&eacute;rentes &eacute;tapes
de la connexion. Xstartup (et Xstartup_0 pour l'&eacute;cran 0)
contient les commandes &agrave; ex&eacute;cuter juste apr&egrave;s
la connexion. Ces commandes sont lanc&eacute;s en tant que
root.</p>
<p>Le PATH qui est utilis&eacute; pour les utilisateurs se trouve
dans <code>/etc/X11/xdm/xdm-config</code>. Ce sont les
lignes&nbsp;:</p>
<pre>
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
</pre>
C'est le PATH par d&eacute;faut pour les utilisateurs normaux
(<code>userPath</code>), et pour l'utilisateur root
(<code>systemPath</code>) respectivement. Il est tr&egrave;s
important que le r&eacute;pertoire <code>/usr/bin/X11</code> soit
accessible pour les utilisateurs sous X. En effet, si un
utilisateur se connecte &agrave; une autre machine pour lancer une
application X, il faut qu'il aie <code>/usr/bin/X11</code> dans son
PATH car la machine h&ocirc;te ne saura pas qu'il dispose d'un
terminal X.
<p>Apr&egrave;s Xstartup, XDM lance <code>/etc/X11/Xsession</code>
en tant qu'utilisateur final. La configuration locale est contenue
dans le fichier <code>/etc/environment</code> qui est parcouru,
s'il existe, par Xsession. Xsession &eacute;tant
ex&eacute;cut&eacute; par <code>/bin/sh</code>,
<code>/etc/environment</code> doit donc &ecirc;tre un script
<code>sh</code>. Cela interf&egrave;re avec <code>ssh</code> qui
suppose que <code>/etc/environment</code> est un fichier qui ne
contient que des lignes de la forme VARIABLE=VALEUR.</p>
<h2><a name="ss9.2">9.2 xterm -ls</a></h2>
<p>Par d&eacute;faut, le PATH de toutes les commandes lanc&eacute;s
&agrave; partir des menus du gestionnaire de fen&ecirc;tre est
celui h&eacute;rit&eacute; de XDM. Pour en utiliser un autre, il
faut le d&eacute;finir explicitement. Pour lancer un terminal X
avec un PATH "normal", on doit utiliser des options
sp&eacute;ciales. Pour <code>xterm</code>, l'option
<code>-ls</code> (login shell) doit &ecirc;tre utilis&eacute; pour
obtenir un login shell avec le PATH d&eacute;fini dans les fichiers
d'initialisation du shell en question.</p>
<h2><a name="ss9.3">9.3 Menus et boutons du gestionnaire de
fen&ecirc;tre</a></h2>
<p>Le gestionnaire de fen&ecirc;tre h&eacute;rite de
l'environnement de XDM. Tous les programmes lanc&eacute;s par lui
h&eacute;ritent donc de cet environnement.</p>
<p>L'environnement du shell de l'utilisateur n'affecte pas les
programmes qui sont lanc&eacute;s par les menus ou les boutons. Par
exemple, si un programme est lanc&eacute; par un <code>xterm</code>
(<code>xterm -ls</code>), il poss&egrave;de l'environnement par
d&eacute;faut du login shell, par contre s'il est lanc&eacute; par
un menu, il aura l'environnement du gestionnaire de
fen&ecirc;tre.</p>
<h2><a name="s10">10. Commandes "&agrave; retardement" cron et
at</a></h2>
<h2><a name="ss10.1">10.1 cron</a></h2>
<p>C'est le programme <code>cron</code> qui ex&eacute;cute
p&eacute;riodiquement les commandes sp&eacute;cifi&eacute;es dans
<code>/etc/crontab</code> et dans les crontabs des utilisateurs. La
Debian&nbsp;1.3 poss&egrave;de en plus un m&eacute;canisme pour
ex&eacute;cuter les commandes de <code>/etc/cron.daily</code>,
<code>/etc/cron.weekly</code> et <code>/etc/cron.monthly</code>,
respectivement tous les jours, toutes les semaines et tous les
mois.</p>
<p><code>cron</code> est lanc&eacute; par les scripts de
d&eacute;marrage mais il change son PATH en une valeur assez
&eacute;trange&nbsp;:</p>
<pre>
       /usr/bin:/binn:/sbin:/bin:/usr/sbin:/usr/bin
</pre>
<b>IL S'AGIT SUREMENT D'UN BOGUE DANS CRON.</b> Il s'agit en fait
du PATH de init (<code>/usr/bin:/bin</code>) qui est copi&eacute;
ici, mais sans le 0 terminal (cha&icirc;ne en convention C - NdT)!
Ce bogue n'existe pas sur tous les syst&egrave;mes.
<p>Dans la crontab, on peut d&eacute;finir un PATH
sp&eacute;cifique pour l'ex&eacute;cution des commandes. Pour la
Debian&nbsp;1.3, il s'agit de&nbsp;:</p>
<pre>
    PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
</pre>
De cette fa&ccedil;on, le PATH de <code>crond</code> n'est jamais
utilis&eacute; dans les programmes utilisateurs. Tous les scripts
de <code>/etc/cron.*</code> obtiennent par d&eacute;faut le PATH de
la crontab. Celui ci est utilis&eacute; m&ecirc;me si le programme
n'est pas ex&eacute;cut&eacute; en tant que root.
<h2><a name="ss10.2">10.2 at</a></h2>
<p>La commande <code>at</code> est utilis&eacute;e pour lancer un
programme &agrave; une heure fix&eacute;e.</p>
<p>Le programme <code>atd</code> est lanc&eacute; avec le PATH de
<code>init</code>. Cependant, les programmes sont toujours
lanc&eacute;s avec l'environnement utilisateur gr&acirc;ce &agrave;
<code>sh</code>. Les sp&eacute;cificit&eacute;s de <code>sh</code>
s'appliquent donc ici. Reportez vous au chapitre sur
<code>bash</code>.</p>
<h2><a name="s11">11. Quelques exemples</a></h2>
<h2><a name="ss11.1">11.1 magicfilter</a></h2>
<p><code>magicfilter</code> est un outil standard permettant de
manipuler les fichiers &agrave; destination de l'imprimante. Il
analyse le type du fichier &agrave; imprimer et lance un filtre
appropri&eacute; pour l'imprimer de la meilleure fa&ccedil;on. Les
scripts utilis&eacute;s pour filtrer sont lanc&eacute;s par
<code>lpd</code>, lui m&ecirc;me lanc&eacute; par le script
<code>/etc/init.d/lpd</code> lanc&eacute; par <code>init</code>. Le
PATH est donc identique &agrave; celui de <code>init</code> et ne
contient donc pas <code>/usr/bin/X11</code>.</p>
<p>Si vous voulez envoyer des fichier PDF (Portable Data Format)
&agrave; <code>magicfilter</code>, vous pouvez utiliser
<code>/usr/bin/X11/xpdf</code>. Mais vous ne devez pas oublier
d'indiquer le chemin absolu. Sinon, <code>magicfilter</code> ne
trouvera pas <code>xpdf</code>. La plupart des programmes
utilis&eacute;s avec <code>magicfilter</code>, ne
n&eacute;cessitent pas forcement un chemin explicite car ils se
trouvent souvent dans <code>/bin</code> ou
<code>/usr/bin</code>.</p>
<h2><a name="ss11.2">11.2 Impression &agrave; partir d'applications
X</a></h2>
<p>Au cas o&ugrave; vous utilisez la variable d'environnement
PRINTER pour s&eacute;lectionner l'imprimante &agrave; utiliser,
vous devez savoir que dans certains cas, certaines applications X
risquent de ne pas la conna&icirc;tre.</p>
<p>Vous vous souvenez s&ucirc;rement que si la session X a
&eacute;t&eacute; lanc&eacute; par XDM, le gestionnaire de
fen&ecirc;tre ne se sert pas de vos scripts de login. Toutes les
applications X que vous lancez &agrave; partir d'un
<code>xterm</code> poss&egrave;dent donc la variable PRINTER. Par
contre, la m&ecirc;me application lanc&eacute;e &agrave; partir
d'un menu ou d'un bouton ne poss&eacute;dera pas cette
variable.</p>
<p>Parfois, la variable PRINTER peut &ecirc;tre
h&eacute;rit&eacute;e &agrave; un niveau encore plus bas. Par
exemple, une application auxiliaire de Netscape pourra
conna&icirc;tre votre variable PRINTER m&ecirc;me si Netscape ne la
conna&icirc;t pas.</p>
<h2><a name="s12">12. Questions de s&eacute;curit&eacute;</a></h2>
<p>Le m&eacute;canisme de PATH est souvent un gros probl&egrave;me
du point de vue s&eacute;curit&eacute;. Utiliser une erreur dans la
d&eacute;finition du PATH est une mani&egrave;re fr&eacute;quente
de pirater un syst&egrave;me. Il est facile pour un pirate de
fabriquer des chevaux de Troie, s'il arrive &agrave; forcer root ou
un autre utilisateur &agrave; ex&eacute;cuter ses propres
programmes.</p>
<p>Une erreur fr&eacute;quente par le pass&eacute; (?) &eacute;tait
de laisser le r&eacute;pertoire courant '.' dans le PATH de
l'utilisateur root. Un pirate malveillant peut alors cr&eacute;er
son propre programme <code>'ls'</code> dans son r&eacute;pertoire.
Ensuite, si root fait&nbsp;:</p>
<pre>
    # cd ~pirate
    # ls
</pre>
il ex&eacute;cute le programme du pirate...
<p>De la m&ecirc;me fa&ccedil;on, cela s'applique &agrave; tous les
programmes ex&eacute;cut&eacute;s par root. Aucun important
d&eacute;mon ne devrait ex&eacute;cuter quoi que ce soit qui puisse
&ecirc;tre modifi&eacute; par un utilisateur. Dans certains
syst&egrave;mes, <code>/usr/local/bin</code> peut contenir des
programmes jug&eacute;s moins s&ucirc;r, mais le r&eacute;pertoire
est retir&eacute; du PATH de root. Cependant, si on sait qu'un
d&eacute;mon ex&eacute;cute <code>bidule</code> avec
'PATH=/usr/local/bin:...', il est possible de tromper le
d&eacute;mon en lui faisant ex&eacute;cuter
<code>/usr/local/bin/bidule</code> &agrave; la place de
<code>/bin/bidule</code>. Dans ce cas, n'importe qui pouvant
&eacute;crire dans <code>/usr/local/bin</code> peut s&ucirc;rement
pirater le syst&egrave;me.</p>
<p>Il est donc tr&egrave;s important de faire attention &agrave;
l'ordre dans lequel les r&eacute;pertoires sont plac&eacute;s dans
le PATH. Si <code>/usr/local/bin</code> se trouve avant
<code>/bin</code>, il y a un risque. Alors que s'il se trouve
apr&egrave;s, il est impossible de lancer la commande
modifi&eacute;e <code>/usr/local/bin/bidule</code> &agrave; la
place de <code>/bin/bidule</code>.</p>
<p>Sous Linux, vous devez vous souvenir que la recherche dans le
PATH est fa&icirc;te dans tous les m&eacute;canismes d'appels du
syst&egrave;me d'exploitation. N'importe o&ugrave;, o&ugrave; le
chemin d'un ex&eacute;cutable est donn&eacute;, vous pouvez
utiliser le nom de la commande seul qui sera alors cherch&eacute;e
au moins dans <code>/bin</code> et <code>/usr/bin</code>, et
vraisemblablement dans beaucoup d'autres endroits.</p>
<h2><a name="s13">13. Comment r&eacute;soudre les
probl&egrave;mes&nbsp;?</a></h2>
<p>La commande la plus simple pour avoir acc&egrave;s &agrave;
l'environnement est <code>/usr/bin/env</code>.</p>
<p>Il est egalement possible d'utiliser le r&eacute;pertoire
<code>/proc</code> pour trouver le PATH de n'importe quel
programme. Vous devez d'abord conna&icirc;tre le num&eacute;ro de
processus du programme. Utilisez la commande <code>ps</code> pour
l'obtenir. Par exemple, si <code>xterm</code> est le processus
num&eacute;ro 1088, vous pouvez voir son environnement
avec&nbsp;:</p>
<pre>
    # more /proc/1088/environ
</pre>
Cela ne marche pas avec des processus comme <code>xdm</code>. Pour
acc&eacute;der &agrave; l'environnement d'un processus du
syst&egrave;me ou d'un autre utilisateur, vous devez &ecirc;tre
root.
<p>Pour deboguer Netscape, vous pouvez cr&eacute;er le script
suivant&nbsp;:</p>
<pre>
    $ cat &gt; /tmp/test
    #!/bin/sh
    /usr/bin/env &gt; /tmp/env
    ^d
    $ chmod +x /tmp/test
</pre>
Ensuite, arrangez vous pour que votre programme soit appel&eacute;
&agrave; la place d'une application auxiliaire, par exemple
RealAudio (<code>audio/x-pn-realaudio</code>). Lorsque vous
essayerez d'acc&eacute;der &agrave; un lien RealAudio (quelque
chose comme <code>http://www.realaudio.com/showcase</code>),
Netscape lancera votre programme factice et sauvera l'environnement
dans <code>/tmp/env</code>.
<h2><a name="s14">14. M&eacute;thodes pour que tous les
utilisateurs aient le m&ecirc;me PATH</a></h2>
<p>Le r&eacute;glage le plus important est &agrave; faire dans les
fichiers commun d'initialisation des logins shells&nbsp;:
<code>/etc/csh.login</code> pour <code>tcsh</code> et
<code>/etc/profile</code> pour <code>bash</code>.</p>
<p>Ceux qui n'obtiennent pas le bon PATH &agrave; partir de ces
fichiers sont&nbsp;: <code>rsh</code>, <code>ssh</code>, les
&eacute;l&eacute;ments des menus du gestionnaire de fen&ecirc;tres
sous X ne lan&ccedil;ant pas explicitement de login shell, les
commandes lanc&eacute;s &agrave; partir de <code>inittab</code>,
les travaux de <code>cron</code>, les travaux des d&eacute;mons
comme <code>magicfilter</code> (lanc&eacute; par
<code>lprd</code>), les scripts CGI (WWW), etc...</p>
<p>Si le PATH est fix&eacute; dans <code>/etc/csh.cshrc</code>, il
sera utilis&eacute; si <code>rsh</code> ou <code>ssh</code> lance
des commandes sur une machine distante o&ugrave; l'utilisateur
utilise <code>tcsh/csh</code>. Par contre, il n'est pas possible de
r&eacute;gler le PATH si l'utilisateur utilise
<code>bash/sh</code>. Voici une m&eacute;thode pour ne garder le
PATH que dans un seul fichier, par exemple
<code>/etc/environnement-commun</code>, dans lequel on
&eacute;crit&nbsp;:</p>
<pre>
  ${EXPORT}PATH${EQ}/bin:/usr/bin:/sbin:/usr/sbin:/usr/bin/X11:/usr/local/bin:/usr/games:.
</pre>
On peut ensuite l'utiliser &agrave; partir de
<code>/etc/csh.login</code> (pour <code>tcsh</code> et
<code>csh</code>)
<pre>
  set EQ=" " set EXPORT="setenv "; source /etc/environnement-commun
</pre>
A partir de <code>/etc/profile</code> (pour <code>bash</code>, mais
pas pour le vrai <code>sh</code>)
<pre>
  EQ='=' EXPORT="export " . /etc/environnement-commun
</pre>
Et &agrave; partir de <code>/etc/environment</code> (pour XDM)
<pre>
  EQ='=' EXPORT="export " . /etc/environnement-commun
</pre>
<p>Cette m&eacute;thode marchera la plupart du temps, sauf que
<code>ssh</code> se plaindra des lignes contenues dans
<code>/etc/environment</code> (ainsi que des variables EQ et
EXPORT). De plus, <code>rsh</code> n'aura toujours pas le bon PATH
s'il passe par <code>bash</code>.</p>
<h2><a name="s15">15. Remerciements</a></h2>
<p>Une des raisons pour commencer l'&eacute;criture de ce document
a &eacute;t&eacute; la grosse frustration de Ari Mujunen. Juha
Takala m'a donn&eacute; de pr&eacute;cieux commentaires.</p>
</body>
</html>