Page suivante Page précédente Table des matières

8. Serveurs

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.

8.1 inetd

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).

8.2 rsh

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
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.

8.3 rlogin

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.

8.4 telnet

Le programme telnet est similaire à rlogin : il utilise le programme login et la ligne de commande utilisée est de la même forme.

8.5 ssh

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.


Page suivante Page précédente Table des matières