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.