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.
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).
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_commandeO�
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.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_utilisateurL'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.Le programme telnet est similaire � rlogin :
il utilise le programme login et la ligne de commande
utilis�e est de la m�me forme.
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/binLa 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 xtermne 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.
Hosting by: Hurra Communications GmbH
Generated: 2007-01-26 18:01:28