PATH Mini-HowTo
Esa Turtiainen (
[email protected])
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 fran�aise par Mathieu Lafon (
[email protected]),
r�alis�e le 22 Octobre 1998.
11.. IInnttrroodduuccttiioonn
Ce document aborde les astuces et les probl�mes relatifs aux variables
d'environnement sous Unix/Linux, et plus sp�cialement � la variable
PATH. PATH est une liste de r�pertoires dans lesquels le syst�me
recherche les commandes � ex�cuter. Ce document s'appuie sur la
distribution Debian Linux 1.3.
Remarque: Ce document est en phase de d�veloppement (b�ta). Vous
pouvez m'envoyer vos commentaires ou vos corrections.
Les commentaires sur la traduction sont � envoyer � Mathieu Lafon
(
[email protected]).
22.. DDrrooiittss dd''aauutteeuurr
Cette documentation est libre, vous pouvez la redistribuer et/ou la
modifier selon les termes de la Licence Publique G�n�rale GNU publi�e
par la Free Software Foundation (version 2 ou bien toute autre version
ult�rieure choisie par vous).
Cette documentation est distribu�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�cifique.
Reportez-vous � la Licence Publique G�n�rale GNU pour plus de d�tails.
Vous pouvez obtenir une copie de la Licence Publique G�n�rale GNU en
�crivant � la Free Software Foundation, Inc., 675 Mass Ave, Cambridge,
MA 02139, Etats-Unis.
33.. GG��nn��rraalliitt��ss
Tous les processus sous Unix poss�dent 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 cha�nes (pouvant contenir la majorit� des caract�res). Tous
les processus Unix poss�dent un processus parent, celui qui les a
cr��s. Les processus fils h�ritent 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
pr�sente sous la forme d'une liste de r�pertoires s�par�s par le
caract�re deux-points (':'). Ces r�pertoires sont parcourus pour
rechercher les commandes. Si vous essayez de lancer la commande
bidule, tous les r�pertoires contenus dans PATH seront examin�s (dans
l'ordre), � la recherche de l'ex�cutable bidule (un fichier avec le
bit ex�cutable positionn�). Si un tel fichier est trouv�, il sera
ex�cut�.
Dans ce document, j'utilise le terme de _c_o_m_m_a_n_d_e pour un programme
ex�cutable qui est appel� sans indication de son chemin, utilisant
donc le m�canisme de PATH.
Sous Linux, m�me les appels de bas niveau pour lancer des processus
(la famille des exec) se basent sur la variable PATH pour trouver les
ex�cutables : vous pouvez donc utiliser le m�canisme de PATH n'importe
o�, o� vous voulez ex�cuter une commande. Si un appel de exec re�oit
le nom d'un fichier qui ne contient pas de '/', il cherchera dans la
variable d'environnement PATH. M�me si cette variable n'existe pas,
les r�pertoires /bin et /usr/bin seront examin�s � la recherche de
cette commande.
Pour cr�er 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 conna�tre les vari�
ables de l'environnement courant. Elle peut �galement �tre utilis�e
pour les modifier.
Pour trouver plus d'information sur les commandes d'acc�s �
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 d�marre, 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'anc�tre 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 sp�cifi�s dans le
fichier /etc/inittab. Ces processus travaillent dans un environnement
directement h�rit� 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 syst�me est souvent
effectu�e 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 syst�me comprend plusieurs d�mons qui peuvent ou non utiliser
l'environnement par d�faut. La plupart de ceux-ci sont lanc� par les
scripts d'initialisation et poss�dent donc l'environnement de init.
Quand un utilisateur se connecte, l'environnement est modifi� par les
param�tres contenus dans les programmes, les scripts d'initialisation
communs � tous, et ceux sp�cifiques � l'utilisateur. C'est assez
compliqu� et la situation n'est pas compl�tement satisfaisante. En
effet, le comportement est totalement diff�rent suivant que
l'utilisateur se connecte � partir du terminal texte, de XDM ou du
r�seau.
44.. iinniitt
init est le processus parent de tous les autres processus du syst�me.
Ceux-ci h�ritent de son environnement et m�me 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 r�pertoire /usr/local/bin.
Tous les programmes qui sont lanc�s � 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 poss�de par
d�faut l'environnement de init. Par exemple, syslogd, kerneld, pppd
(lorsqu'il est lanc� au d�marrage), gpm, et ce qui est le plus
important, lpd et inetd poss�dent l'environnement de init et ne le
modifient pas.
Un certain nombre de programmes sont lanc�s par les scripts de
d�marrage mais avec une variable PATH explicitement fix�e dans le
script. Les exemples de tels programmes sont atd, sendmail, apache et
squid.
D'autre programmes, par exemple cron, sont lanc�s par les scripts mais
modifient totalement la variable PATH.
55.. CCoonnnneexxiioonn
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 d�fini 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 r�pertoires sbin.
Cependant, il contient le r�pertoire courant '.', qui est consid�r�
comme dangereux pour l'utilisateur root. M�me /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 poss�de exactement le PATH du
login.
etu-ppp:viYabVlxPwzDl:1000:1000:Esa Turtiainen, PPP:/:/usr/sbin/pppd
66.. SShheellllss
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 pr�c�d� d'un '-'. Par
exemple, dans le cas de bash, on aura -bash. Cela indique au shell
qu'il est en pr�sence d'un login shell et qu'il doit dans ce cas
ex�cuter les fichiers d'initialisation sp�cifiques � la connexion.
Dans le cas contraire, on aura une initialisation plus l�g�re. De
plus, le shell d�termine 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 tr�s peu d'initialisation (bash n'ex�cute aucune
initialisation dans ce cas l�).
66..11.. bbaasshh
Pour un login shell normal, bash parcourt le fichier /etc/profile,
commun � tous, o� les variables d'environnement, dont PATH, peuvent
�tre fix�es pour les utilisateurs de bash. Cependant, ce fichier n'est
pas relu lorsque le syst�me se trouve face � un shell non interactif.
Le cas le plus important est rsh, o� la commande est ex�cut�e sur la
machine voisine : le fichier /etc/profile n'est pas lanc� et le PATH
provient du d�mon de rsh.
bash accepte les arguments -login et -i qui sont utilis�s pour obtenir
respectivement un login shell et/ou un shell interactif.
L'utilisateur peut red�finir les param�tres contenus dans /etc/profile
en cr�ant un fichier ~/.bash_profile, ~/.bash_login ou ~/.profile. Il
faut noter que seul le premier fichier sera ex�cut� m�me si cela
diff�re des habitudes de csh. En particulier, ~/.bash_login ne sera
pas forcement ex�cut� 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.
66..22.. ttccsshh
Pour un login shell, tcsh ex�cute dans l'ordre les fichiers suivants :
� /etc/csh.cshrc
� /etc/csh.login
� ~/.tcshrc
� ~/.cshrc (si ~/.tcshrc n'existe pas)
� ~/.history
� ~/.login
� ~/.cshdirs
AAtttteennttiioonn.. tcsh peut �tre compil� pour ex�cuter les scripts de
connexion (login) avant les scripts cshrc.
Les shells non interactifs n'ex�cutent que les scripts *cshrc. Les
scripts *login peuvent �tre utilis�s pour ne fixer le PATH que lors
d'une connexion.
77.. MMooddiiffiieerr ll''iiddeennttiitt�� ddee ll''uuttiilliissaatteeuurr
77..11.. ssuu
La commande su sert � indiquer la nouvelle identit� � utiliser (sous
r�serve de conna�tre le mot de passe), root �tant la valeur par
d�faut.
Normalement, su lance un sous-shell avec la nouvelle identit�. Avec
l'argument '-' (plus r�cemment -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 int�gr� au programme pour simuler le
login (termes employ�s 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 r�alise �galement quelques changements mineurs dans l'environ�
nement.
77..22.. ssuuddoo
Il y a un groupe de commandes qui permettent une utilisation plus s�r
des commandes du super utilisateur. Elles permettent un meilleur suivi
(au sens o� l'on garde une trace de chaque ex�cution - NdT), des
restrictions sur les utilisateurs et utilisent des mots de passe
individuels. La plus utilis�e est s�rement sudo.
$ sudo env
Cette commande ex�cute 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 r�pertoires o� chercher la commande
� ex�cuter pour que le r�pertoire courant soit toujours le dernier.
Cependant, elle ne modifie pas la variable PATH, seulement quelques
variables comme SUDO_USER.
88.. SSeerrvveeuurrss
La majorit� des serveurs ne devrait pas lancer n'importe quelle sorte
de processus. Pour des raisons de s�curit�, leur PATH doit donc �tre
minimal.
La plus grosse exception est l'ensemble des services qui autorisent
une connexion sur le syst�me � partir du r�seau. Cette section d�crit
comment se trouve l'environnement dans ces cas pr�cis. En effet, une
commande ex�cut� � distance avec rsh aura un PATH diff�rent d'une
commande ex�cut� avec ssh. De la m�me fa�on, une connexion � l'aide de
rlogin, telnet ou ssh est diff�rente.
88..11.. iinneettdd
La plupart des serveurs ne poss�dent pas de processus charg�
d'attendre en permanence l'arriv�e d'une requ�te. Ce travail est
laiss� � un super serveur (Internet super server), appel� inetd. Le
programme inetd est � l'�coute permanente du r�seau et lance le
serveur appropri� en fonction du port sur lequel arrive la requ�te.
Son comportement est d�fini dans le fichier /etc/inetd.conf.
inetd est d�marr� par les scripts de d�marrage du syst�me. Il h�rite
donc du PATH de init. Il ne le modifie pas et tous les serveurs
lanc�s par inetd poss�dent donc le PATH de init. Un exemple de tel
serveur est imapd, le serveur du protocole IMAP.
D'autre exemples de processus lanc�s par inetd sont telnetd, rlogind,
talkd, ftp, popd, certains serveurs http, etc...
Souvent, l'utilisation de inetd est compliqu�e par l'utilisation du
programme tcpd, charg� de lancer le v�ritable serveur. C'est un
programme qui effectue quelques v�rifications du point de vue s�curit�
avant de lancer le v�ritable serveur. Il ne touche pas au PATH
(information non v�rifi�e).
88..22.. rrsshh
Le d�mon de rsh utilise le PATH d�fini par _PATH_DEFPATH
(/usr/include/path.h), c'est � dire, le m�me que celui utilis� par le
programme login pour connecter les utilisateurs normaux.
L'utilisateur root obtiendra le m�me PATH que les autres.
En r�alit�, rshd ex�cute la commande d�sir�e en se servant de la
commande suivante :
shell -c ligne_de_commande
O� shell n'est pas un login shell. Il est pr�f�rable que tous les
shells mentionn�s dans /etc/passwd prennent en compte l'option -c pour
pouvoir leur envoyer ce genre de ligne de commande.
88..33.. rrllooggiinn
rlogin invoque login pour effectuer la proc�dure de connexion. Si
vous vous connectez avec rlogin, vous aurez le m�me PATH qu'avec
login. La plupart des autres fa�ons de se connecter � un ordinateur
sous Linux n'utilisent pas login. Notez la diff�rence avec rsh.
La commande de login utilis�e 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.
88..44.. tteellnneett
Le programme telnet est similaire � rlogin : il utilise le programme
login et la ligne de commande utilis�e est de la m�me forme.
88..55.. sssshh
ssh poss�de sa propre variable PATH, � laquelle il ajoute le
r�pertoire o� se trouve ssh. Cela implique souvent que le r�pertoire
/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
probl�mes avec XFree86.
99.. XXFFrreeee8866
99..11.. XXDDMM
XDM est la mani�re la plus courante pour se connecter � partir d'un
terminal graphique. M�me s'il ressemble � login, il se comporte, en
interne, d'une mani�re totalement diff�rente.
Les fichiers de configuration se trouvent dans le r�pertoire
/etc/X11/xdm et sont ex�cut�s pendant les diff�rentes �tapes de la
connexion. Xstartup (et Xstartup_0 pour l'�cran 0) contient les
commandes � ex�cuter juste apr�s la connexion. Ces commandes sont
lanc�s 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 d�faut pour les utilisateurs normaux (userPath), et
pour l'utilisateur root (systemPath) respectivement. Il est tr�s
important que le r�pertoire /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 h�te ne saura pas qu'il dis�
pose d'un terminal X.
Apr�s 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 ex�cut� par /bin/sh, /etc/environment doit donc �tre un
script sh. Cela interf�re avec ssh qui suppose que /etc/environment
est un fichier qui ne contient que des lignes de la forme
VARIABLE=VALEUR.
99..22.. xxtteerrmm --llss
Par d�faut, le PATH de toutes les commandes lanc�s � partir des menus
du gestionnaire de fen�tre est celui h�rit� de XDM. Pour en utiliser
un autre, il faut le d�finir explicitement. Pour lancer un terminal X
avec un PATH "normal", on doit utiliser des options sp�ciales. Pour
xterm, l'option -ls (login shell) doit �tre utilis� pour obtenir un
login shell avec le PATH d�fini dans les fichiers d'initialisation du
shell en question.
99..33.. MMeennuuss eett bboouuttoonnss dduu ggeessttiioonnnnaaiirree ddee ffeenn��ttrree
Le gestionnaire de fen�tre h�rite de l'environnement de XDM. Tous les
programmes lanc�s par lui h�ritent donc de cet environnement.
L'environnement du shell de l'utilisateur n'affecte pas les programmes
qui sont lanc�s par les menus ou les boutons. Par exemple, si un
programme est lanc� par un xterm (xterm -ls), il poss�de
l'environnement par d�faut du login shell, par contre s'il est lanc�
par un menu, il aura l'environnement du gestionnaire de fen�tre.
1100.. CCoommmmaannddeess ""�� rreettaarrddeemmeenntt"" ccrroonn eett aatt
1100..11.. ccrroonn
C'est le programme cron qui ex�cute p�riodiquement les commandes
sp�cifi�es dans /etc/crontab et dans les crontabs des utilisateurs. La
Debian 1.3 poss�de en plus un m�canisme pour ex�cuter 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 d�marrage mais il change son PATH en
une valeur assez �trange :
/usr/bin:/binn:/sbin:/bin:/usr/sbin:/usr/bin
IILL SS''AAGGIITT SSUURREEMMEENNTT DD''UUNN BBOOGGUUEE DDAANNSS CCRROONN.. Il s'agit en fait du PATH de
init (/usr/bin:/bin) qui est copi� ici, mais sans le 0 terminal
(cha�ne en convention C - NdT)! Ce bogue n'existe pas sur tous les
syst�mes.
Dans la crontab, on peut d�finir un PATH sp�cifique pour l'ex�cution
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 fa�on, le PATH de crond n'est jamais utilis� dans les pro�
grammes utilisateurs. Tous les scripts de /etc/cron.* obtiennent par
d�faut le PATH de la crontab. Celui ci est utilis� m�me si le pro�
gramme n'est pas ex�cut� en tant que root.
1100..22.. aatt
La commande at est utilis�e pour lancer un programme � une heure
fix�e.
Le programme atd est lanc� avec le PATH de init. Cependant, les
programmes sont toujours lanc�s avec l'environnement utilisateur gr�ce
� sh. Les sp�cificit�s de sh s'appliquent donc ici. Reportez vous au
chapitre sur bash.
1111.. QQuueellqquueess eexxeemmpplleess
1111..11.. mmaaggiiccffiilltteerr
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
fa�on. Les scripts utilis�s pour filtrer sont lanc�s par lpd, lui m�me
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 utilis�s avec
magicfilter, ne n�cessitent pas forcement un chemin explicite car ils
se trouvent souvent dans /bin ou /usr/bin.
1111..22.. IImmpprreessssiioonn �� ppaarrttiirr dd''aapppplliiccaattiioonnss XX
Au cas o� vous utilisez la variable d'environnement PRINTER pour
s�lectionner l'imprimante � utiliser, vous devez savoir que dans
certains cas, certaines applications X risquent de ne pas la
conna�tre.
Vous vous souvenez s�rement que si la session X a �t� lanc� par XDM,
le gestionnaire de fen�tre ne se sert pas de vos scripts de login.
Toutes les applications X que vous lancez � partir d'un xterm
poss�dent donc la variable PRINTER. Par contre, la m�me application
lanc�e � partir d'un menu ou d'un bouton ne poss�dera pas cette
variable.
Parfois, la variable PRINTER peut �tre h�rit�e � un niveau encore plus
bas. Par exemple, une application auxiliaire de Netscape pourra
conna�tre votre variable PRINTER m�me si Netscape ne la conna�t pas.
1122.. QQuueessttiioonnss ddee ss��ccuurriitt��
Le m�canisme de PATH est souvent un gros probl�me du point de vue
s�curit�. Utiliser une erreur dans la d�finition du PATH est une
mani�re fr�quente de pirater un syst�me. Il est facile pour un pirate
de fabriquer des chevaux de Troie, s'il arrive � forcer root ou un
autre utilisateur � ex�cuter ses propres programmes.
Une erreur fr�quente par le pass� (?) �tait de laisser le r�pertoire
courant '.' dans le PATH de l'utilisateur root. Un pirate malveillant
peut alors cr�er son propre programme 'ls' dans son r�pertoire.
Ensuite, si root fait :
# cd ~pirate
# ls
il ex�cute le programme du pirate...
De la m�me fa�on, cela s'applique � tous les programmes ex�cut�s par
root. Aucun important d�mon ne devrait ex�cuter quoi que ce soit qui
puisse �tre modifi� par un utilisateur. Dans certains syst�mes,
/usr/local/bin peut contenir des programmes jug�s moins s�r, mais le
r�pertoire est retir� du PATH de root. Cependant, si on sait qu'un
d�mon ex�cute bidule avec 'PATH=/usr/local/bin:...', il est possible
de tromper le d�mon en lui faisant ex�cuter /usr/local/bin/bidule � la
place de /bin/bidule. Dans ce cas, n'importe qui pouvant �crire dans
/usr/local/bin peut s�rement pirater le syst�me.
Il est donc tr�s important de faire attention � l'ordre dans lequel
les r�pertoires sont plac�s dans le PATH. Si /usr/local/bin se trouve
avant /bin, il y a un risque. Alors que s'il se trouve apr�s, il est
impossible de lancer la commande modifi�e /usr/local/bin/bidule � la
place de /bin/bidule.
Sous Linux, vous devez vous souvenir que la recherche dans le PATH est
fa�te dans tous les m�canismes d'appels du syst�me d'exploitation.
N'importe o�, o� le chemin d'un ex�cutable est donn�, vous pouvez
utiliser le nom de la commande seul qui sera alors cherch�e au moins
dans /bin et /usr/bin, et vraisemblablement dans beaucoup d'autres
endroits.
1133.. CCoommmmeenntt rr��ssoouuddrree lleess pprroobbll��mmeess ??
La commande la plus simple pour avoir acc�s � l'environnement est
/usr/bin/env.
Il est egalement possible d'utiliser le r�pertoire /proc pour trouver
le PATH de n'importe quel programme. Vous devez d'abord conna�tre le
num�ro de processus du programme. Utilisez la commande ps pour
l'obtenir. Par exemple, si xterm est le processus num�ro 1088, vous
pouvez voir son environnement avec :
# more /proc/1088/environ
Cela ne marche pas avec des processus comme xdm. Pour acc�der �
l'environnement d'un processus du syst�me ou d'un autre utilisateur,
vous devez �tre root.
Pour deboguer Netscape, vous pouvez cr�er 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'acc�der � un lien RealAudio
(quelque chose comme
http://www.realaudio.com/showcase), Netscape
lancera votre programme factice et sauvera l'environnement dans
/tmp/env.
1144.. MM��tthhooddeess ppoouurr qquuee ttoouuss lleess uuttiilliissaatteeuurrss aaiieenntt llee mm��mmee PPAATTHH
Le r�glage 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 �l�ments des menus du gestionnaire de fen�tres sous X ne
lan�ant pas explicitement de login shell, les commandes lanc�s �
partir de inittab, les travaux de cron, les travaux des d�mons 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 r�gler le PATH si
l'utilisateur utilise bash/sh. Voici une m�thode 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 m�thode 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.
1155.. RReemmeerrcciieemmeennttss
Une des raisons pour commencer l'�criture de ce document a �t� la
grosse frustration de Ari Mujunen. Juha Takala m'a donn� de pr�cieux
commentaires.
