mini-HOWTO : Comment exécuter des applications X à distance <author><htmlurl url="http://www.xs4all.nl/~zweije/" name="Vincent Zweije">, <htmlurl url="mailto:zweije@xs4all.nl" name="zweije@xs4all.nl"> <date>V 0.6.3, 11 juillet 2000 <abstract> Ce mini-HOWTO décrit comment exécuter des applications X à distance. C'est-à-dire, comment faire pour qu'un programme X s'affiche sur un écran d'ordinateur différent de celui sur lequel il s'exécute. Ou, autrement dit, comment faire tourner un programme X sur un ordinateur différent de celui devant lequel vous êtes assis. L'accent de ce mini-HOWTO sera mis sur les questions de sécurité. Ce mini-HOWTO contient également des informations sur la manière de faire tourner des applications X en local, mais avec un identificateur d'utilisateur (user-id) différent. Adaptation française : Albert-Paul Bouillot <htmlurl url="mailto:apb@club-internet.fr" name="apb@club-internet.fr"> </abstract> <toc> <sect> Introduction Ce mini-HOWTO constitue un guide sur la manière de faire tourner des applications X à distance. J'ai rédigé ce document pour plusieurs raisons : <enum> <item> Il y a eu de nombreuses questions, sur Usenet, sur la manière de faire tourner des applications X à distance; <item> J'ai vu beaucoup, beaucoup, de conseils d'utilisation de '' <tt>xhost +hostname</tt>'' ou même de ''<tt>xhost +</tt>'' pour réaliser des connexions X. <bf>C'est d'une insécurité totale</bf>, et il existe de bien meilleures méthodes; <item> Je n'ai pas connaissance d'un document simple décrivant les options dont on peut disposer. Si vous avez des informations complémentaires, s'il vous plaît, faites-le moi savoir : <htmlurl url="mailto:zweije@xs4all.nl" name="<zweije@xs4all.nl>">. </enum> Ce document a été écrit en pensant à des systèmes de type Unix. Si le système d'exploitation de votre ordinateur local ou de celui qui est à distance est de type différent, vous devriez trouver ici des informations sur la manière dont les choses se passent. Cependant, il vous faudra modifier les exemples par vous-même pour les utiliser sur votre (vos) propre(s) systèmes(s). La version (anglaise) la plus récente de ce document est toujours disponible sur le WWW à <htmlurl url="http://www.xs4all.nl/~zweije/xauth.html" name="http://www.xs4all.nl/˜zweije/xauth.html">. Il est également disponible en tant que mini-HOWTO Linux Applications X à distance (Remote X Apps) à : <htmlurl url="http://sunsite.unc.edu/LDP/HOWTO/mini/Remote-X-Apps" name="http://sunsite.unc.edu/LDP/HOWTO/mini/Remote-X-Apps">. Les (mini-)HOWTOs Linux sont disponibles par http ou ftp sur <htmlurl url="http://sunsite.unc.edu/LDP/HOWTO/HOWTO-INDEX-2.html" name="sunsite.unc.edu">. Ceci constitue la version 0.6.3. Aucunes garanties, seulement de bonnes intentions. Je suis ouvert aux suggestions, idées, ajouts, pointeurs utiles, corrections (typo), etc... Je veux que cela reste un document simple et lisible, dans la bonne moyenne du style HOWTO. Les querelles seront redirigées vers /dev/null. Le contenu de ce mini-HOWTO a été mis à jour le 11 juillet 2000 par <htmlurl url="http://www.xs4all.nl/~zweije/index.html" name="Vincent Zweije"> <sect> Lectures complémentaires Un document, en rapport avec cela, sur le WWW traite de ''Quoi faire quand Tk dit que votre écran n'est pas sûr'', <htmlurl url="http://ce-toolkit.crd.ge.com/tkxauth/" name="http://ce-toolkit.crd.ge.com/tkxauth/">. Il a été écrit par <htmlurl url="http://ce-toolkit.crd.ge.com/people/kennykb.html" name="Kevin Kenny">. Il suggère une solution similaire à celle de ce document pour l'authentification X (xauth). Cependant, Kevin vise plus à l'utilisation de xdm pour diriger xauth à votre place. On m'a indiqué que le volume 8 du ``Guide de l'administrateur du système X Window'' (X Window System Administrator's Guide Vol. 8) de chez <htmlurl url="http://www.ora.com/" name="O'Reilly and Associates"> était une bonne source d'informations. Malheureusement, je n'ai pas pu le vérifier. Il y a également un autre document qui ressemble beaucoup à celui que vous êtes en train de lire, dont le titre est ''Securing X Windows'', et qui est disponible à <htmlurl url="http://ciac.llnl.gov/ciac/documents/ciac2316.html" name="http://ciac.llnl.gov/ciac/documents/ciac2316.html">. Consultez également les listes de diffusion usenet, telles que : <tt/comp.windows.x/, <tt/comp.os.linux.x/, et <tt/comp.os.linux.networking/. <sect> Le contexte Vous utilisez deux ordinateurs. Sur le premier, vous êtes dans l'environnement X Window pour taper au clavier et regarder l'écran. Sur le second vous effectuez un important traitement graphique. Vous voulez que les sorties du second soient affichées sur l'écran du premier. Le système X window rend cela possible. Naturellement, vous devez disposer d'une connexion à un réseau pour pouvoir le réaliser. De préférence rapide, car le protocole X est un dévoreur de ressources réseau. Mais, avec un peu de patience et un protocole de compression de données adapté, vous pouvez même faire tourner des applications par l'intermédiaire d'un modem. Pour un protocole de compression pour X, vous pouvez aller consulter les sites : dxpc <htmlurl url="http://www.vigor.nu/dxpc/" name="http://www.vigor.nu/dxpc/"> ou LBX <url url="http://www.paulandlesley.org/faqs/LBX-HOWTO.html" name="http://www.paulandlesley.org/faqs/LBX-HOWTO.html"> (également connu comme <htmlurl url="http://sunsite.unc.edu/LDP/HOWTO/mini/LBX" name="LBX mini-HOWTO">). Vous avez deux choses à faire pour réaliser tout cela : <enum> <item> Indiquer à l'unité d'affichage locale (le serveur) qu'elle doit accepter les connexions venant de l'ordinateur à distance. <item> Dire à l'application à distance (le client) de rediriger ses sorties vers votre unité d'affichage locale. </enum> <sect> Un peu de théorie Le mot magique est <tt>DISPLAY (unité d'affichage)</tt>. Dans le système X window, une unité d'affichage est constituée (en simplifiant) d'un clavier, d'un mulot et d'un écran. Une unité d'affichage est gérée par un programme serveur, plus connu sous le nom de serveur X. Le serveur fourni des fonctionnalités d'affichage aux autres programmes qui se connectent à lui. Une unité d'affichage est identifiée par un nom, de type, par exemple : <itemize> <item> <tt/DISPLAY=light.uni.verse:0/ <item> <tt/DISPLAY=localhost:4/ <item> <tt/DISPLAY=:0/ </itemize> Un nom d'unité d'affichage est constitué d'un nom d'hôte (par exemple : <tt>light.uni.verse</tt> et <tt>localhost</tt>), du signe deux point (<tt/:/), et d'un numéro de séquence (tels que <tt/0/ et <tt/4/). Le nom d'hôte de l'unité d'affichage est le nom de l'ordinateur sur lequel tourne le serveur X. Si le nom de l'hôte est omis, cela signifie qu'il s'agit de l'ordinateur local. D'habitude, le numéro de séquence est 0 -- cela peut changer s'il y a plusieurs unités d'affichage connectées sur le même ordinateur. Si jamais il vous arrive de voir le nom d'une unité d'affichage avec un <tt/.n/ supplémentaire accolé à son nom, c'est qu'il s'agit d'un numéro d'écran. Une unité d'affichage peut, en théorie, avoir plusieurs écrans. Cependant, d'habitude, il n'y en a qu'un, qui porte le numéro <tt/n=0/, et c'est le numéro par défaut. D'autres formes de <tt>DISPLAY</tt> existent, mais celle-ci suffira pour notre propos. Pour celui qui est curieux de technique : <itemize> <item> <tt/hostname:D.S/ signifie écran <tt/S/ sur unité d'affichage <tt/D/ de l'hôte <tt/hostname/; le serveur X de cette unité d'affichage est à l'écoute du port TCP <tt/6000+D/. <item> <tt>host/unix:D.S</tt> signifie écran <tt/S/ sur unité d'affichage <tt/D/ de l'hôte <tt/host/; le serveur X de cette unité d'affichage est à l'écoute du socket de domaine UNIX <tt>/tmp/.X11-unix/XD</tt> (et donc, seul <tt/host/ peut l'atteindre). <item> <tt/:D.S/ est équivalent à <tt>host/unix:D.S</tt>, où <tt/host/ est le nom de l'hôte local. </itemize> <sect> Dire au client ... Le programme client (par exemple, votre application graphique) sait à quelle unité d'affichage il doit se connecter en consultant la variable d'environnement <tt>DISPLAY</tt>. Cependant ce paramètrage peut être modifié, en lançant le client avec l'argument <tt>-display hostname:0</tt> dans la ligne de commande. Quelques exemples peuvent clarifier les choses. Notre ordinateur est connu du monde extérieur sous le nom light, et nous sommes dans le domaine uni.verse. Si nous fonctionnons avec un serveur X normal, l'unité d'affichage est connue comme étant <tt/light.uni.verse:0/. Nous voulons faire tourner le programme de dessin xfig sur un ordinateur à distance, appelé <tt/dark.matt.er/, et afficher sa sortie ici, sur light. Supposons que vous vous soyez déjà connecté par telnet à l'ordinateur distant, <tt/dark.matt.er/. Si l'interpréteur de commande de l'ordinateur éloigné est csh : <tscreen><verb> dark% setenv DISPLAY light.uni.verse:0 dark% xfig & </verb></tscreen> Ou, d'une autre manière : <tscreen><verb> dark% xfig -display light.uni.verse:0 & </verb></tscreen> Si c'est sh qui tourne sur l'ordinateur à distance : <tscreen><verb> dark$ DISPLAY=light.uni.verse:0 dark$ export DISPLAY dark$ xfig & </verb></tscreen> Ou, autrement : <tscreen><verb> dark$ DISPLAY=light.uni.verse:0 xfig & </verb></tscreen> Ou, bien sûr, également : <tscreen><verb> dark$ xfig -display light.uni.verse:0 & </verb></tscreen> Il paraît que certaines versions de telnet transmettent automatiquement la variable <tt>DISPLAY</tt> à l'ordinateur hôte éloigné. Si vous avez l'une ce celles-ci, vous avez de la chance, et c'est effectivement automatique. Si ce n'est pas le cas, la plupart des versions de telnet doivent transmettre la variable d'environnement <tt>TERM</tt>, et avec un bidouillage judicieux, il est possible de superposer la variable <tt>DISPLAY</tt> sur la variable <tt>TERM</tt>. L'idée, sous-jacente à cette superposition, est de réaliser une sorte de script pour effectuer ceci : avant la connexion par telnet, donner la valeur de <tt/DISPLAY/ à <tt/TERM/. Puis de lancer telnet. Du côté de l'ordinateur distant, dans le fichier <tt/.*shrc/ concerné, lire la valeur de <tt/DISPLAY/ à partir de <tt/TERM/. <sect> Dire au serveur ... Le serveur n'acceptera pas de connexions venant de n'importe où. Vous ne voulez pas que n'importe qui puisse afficher des fenêtres sur votre écran. Ou lire ce vous tapez -- souvenez-vous que votre clavier fait partie de votre unité d'affichage! Trop peu de gens semble réaliser que permettre l'accès à leur unité d'affichage pose des problèmes de sécurité. Quelqu'un qui dispose d'un accès à votre unité d'affichage peut lire et écrire sur vos écrans, lire vos frappes au clavier, et suivre les déplacements de votre mulot. La plupart des serveurs disposent de deux manières d'authentifier les demandes de connexions qui arrivent : le mécanisme de la liste d'hôtes (xhost) et le mécanisme du mot de passe secret (magic cookie) (xauth). De plus, il y a ssh, l'interpréteur de commande sécurisé, qui peut acheminer les connexions X. <sect1> Xhost Xhost permet les accès basés sur les nom d'hôtes. Le serveur entretient une liste des hôtes qui sont autorisés à se connecter à lui. Il peut aussi désactiver complètement la vérification des hôtes. Attention : cela signifie que plus aucun contrôle n'est effectué, et donc, que n'importe quel hôte peut se connecter! Vous pouvez contrôler la liste des hôtes du serveur avec le programme <tt>xhost</tt>. Pour utiliser ce mécanisme dans l'exemple précédent, faites : <tscreen><verb> light$ xhost +dark.matt.er </verb></tscreen> Ceci permet toutes les connexions à partir de l'hôte <tt>dark.matt.er</tt>. Dès que votre client X a réalisé sa connexion et affiche une fenêtre, par sécurité, supprimez les permissions pour d'autres connexions avec : <tscreen><verb> light$ xhost -dark.matt.er </verb></tscreen> Vous pouvez désactiver la vérification des hôtes avec : <tscreen><verb> light$ xhost + </verb></tscreen> Ceci désactive la vérification des accès des hôtes et donc permet à tout le monde de se connecter. Vous ne devriez jamais faire cela sur un réseau où vous n'avez pas confiance dans tous les utilisateurs (tel internet). Vous pouvez réactiver la vérification des hôtes avec : <tscreen><verb> light$ xhost - </verb></tscreen> <tt>xhost -</tt> par lui-même ne supprime pas tous les hôtes de la liste d'accès (ce qui serait tout à fait inutile - vous ne pourriez plus vous connecter de n'importe où, pas même de votre hôte local). Xhost est un mécanisme vraiment très peu sûr. Il ne fait pas de distinction entre les différents utilisateurs sur l'hôte à distance. De plus, les noms d'hôtes (en réalité des adresses) peuvent être manipulés. C'est mauvais si vous vous trouvez sur un réseau douteux (déjà, par exemple, avec un accès PPP téléphonique à Internet). <sect1> Xauth Xauth autorise l'accès à tous ceux qui connaissent le bon secret. On appelle un tel secret un enregistrement d'autorisation ou cookie. Ce mécanisme d'autorisation est désigné cérémonieusement comme étant le MIT-MAGIC-COOKIE-1. Les cookies pour les différentes unités d'affichage sont stockés ensembles dans <tt>˜/.Xauthority</tt>.Votre fichier <tt>˜/.Xauthority</tt> doit être inaccessible pour les utilisateurs groupe/autres. Le programme xauth gère ces cookies, donc le surnom xauth dans ce schéma. Au démarrage d'une session, le serveur lit un cookie dans le fichier qui est indiqué par l'argument <tt>-auth</tt>. Ensuite, le serveur ne permet la connexion que des clients qui connaissent le même cookie. Quand le cookie dans <tt>˜/.Xauthority</tt> change, <em/le serveur ne récupérera pas la modification/. Les serveurs les plus récents peuvent générer des cookies à la volée pour des clients qui le demandent. les cookies sont cependant encore conservés dans le serveur; ils ne finissent pas dans <tt>˜/.Xauthority</tt> à moins qu'un client ne les y mettent. Selon David Wiggins : <quote> Une possibilité supplémentaire , qui peut vous intéresser, a été ajoutée dans X11R6.3. Par l'intermédiaire de la nouvelle extension SECURITY, le serveur X lui-même peut générer et renvoyer de nouveaux cookies à la volée. De plus on peut désigner les cookies comme étant ``douteux'' de sorte que les applications qui se connectent avec de tels cookies auront une capacité opératoire restreinte. Par exemple, ils ne pourront pas regarder les entrées au clavier/mulot, ou le contenu des fenêtres, d'autres clients ``fiables''. Il y a une nouvelle sous-commande ``generate'' de xauth pour rendre cette fonctionnalité, pas forcément facile, mais au moins possible à utiliser. </quote> Xauth possède un avantage clair, au niveau de la sécurité, sur xhost. Vous pouvez limiter l'accès à des utilisateurs spécifiques sur des ordinateurs spécifiques. Il ne permet pas l'usurpation d'adresse comme le permet xhost. Et, si vous le désirez, vous pouvez encore utiliser xhost en parallèle pour permettre des connexions. <sect2> Fabrication du Cookie Si vous voulez utiliser xauth, vous devez lancer le serveur X avec l'argument <tt>-auth authfile</tt>. Si vous utilisez le script <bf>startx</bf> pour lancer le serveur X, c'est le bon endroit pour le faire. Créez l'enregistrement d'autorisation comme indiqué ci-dessous dans votre script startx. Extrait de <tt>/usr/X11R6/bin/startx</tt>: <tscreen><verb> mcookie|sed -e 's/^/add :0 . /'|xauth -q xinit -- -auth "$HOME/.Xauthority" </verb></tscreen> Mcookie est un petit programme du paquetage util-linux, site primaire <htmlurl url="ftp://ftp.math.uio.no/pub/linux/" name="ftp://ftp.math.uio.no/pub/linux/">. Autrement, vous pouvez utiliser md5sum pour créer quelques données aléatoires (de, par exemple, <tt>/dev/urandom</tt> ou <tt/ps -axl/) au format cookie : <tscreen><verb> dd if=/dev/urandom count=1|md5sum|sed -e 's/^/add :0 . /'|xauth -q xinit -- -auth "$HOME/.Xauthority" </verb></tscreen> Si vous ne pouvez pas éditer le script startx (parce que vous n'êtes pas root), demandez à votre administrateur de système de configurer startx correctement, ou, à la place, laissez-le configurer xdm. S'il ne peut, ou ne veut, pas, vous pouvez écrire un script <tt>˜/.xserverrc</tt>. Si vous avez ce script, il sera exécuté par xinit au lieu du véritable serveur X. Alors, vous pourrez lancer le serveur X véritable à partir de ce script avec les arguments adaptés. Pour faire cela, faites utiliser par votre <tt>˜/.xserverrc</tt> le <tt>mcookie</tt> de la ligne ci-dessus pour créer un cookie puis lancer le véritable serveur X : <tscreen><verb> #!/bin/sh mcookie|sed -e 's/^/add :0 . /'|xauth -q exec /usr/X11R6/bin/X "$@" -auth "$HOME/.Xauthority" </verb></tscreen> Si vous utilisez xdm pour gérer vos sessions X, vous pouvez utiliser xauth facilement. Définissez les ressources du DisplayManager.authDir dans <tt>/etc/X11/xdm/xdm-config</tt>. Xdm passera l'argument <tt/-auth/ au serveur X à son démarrage. Au moment de la connexion sous xdm, xdm place le cookie dans <tt>˜/.Xauthority</tt> pour vous. Consultez xdm(1) pour de plus amples information. Par exemple, mon <tt>/etc/X11/xdm/xdm-config</tt> contient la ligne suivante : <tscreen><verb> DisplayManager.authDir: /var/lib/xdm </verb></tscreen> <sect2> Transfert du Cookie Maintenant que vous avez lancé votre session X sur le serveur hôte <tt/light.uni.verse/ et que vous avez votre cookie dans <tt>˜/.Xauthority</tt>, il vous faut transférer le cookie sur le client, <tt/dark.matt.er/. Il y a plusieurs façons de le faire. <sect3> Répertoires personnels (home) partagés Le plus simple est que vos répertoires sur <tt>light</tt> et <tt>dark</tt> soient partagés. Les fichiers <tt>˜/.Xauthority</tt> sont les mêmes, donc le cookie est transféré instantanément. Cependant, il y a un piège : lorsque vous mettez un cookie pour <tt/:0/ dans <tt>˜/.Xauthority</tt>, dark va croire que c'est un cookie pour lui au lieu de light. Il faut que vous utilisiez un nom d'hôte explicite à la création du cookie; on ne peut pas faire autrement. Vous pouvez installer le même cookie pour, à la fois, <tt/:0/ et <tt/light:0/ avec un peu d'astuce : <tscreen><verb> #!/bin/sh mcookie|sed -e 's/^/add :0 . /' -e p -e "s/:/$HOST&/"|xauth -q exec /usr/X11R6/bin/X "$@" -auth "$HOME/.Xauthority" </verb></tscreen> <sect3> En utilisant le shell à distance, <tt/rsh/ Si les répertoires home ne sont pas partagés, vous pouvez transférer le cookie au moyen de rsh, le shell à distance : <tscreen><verb> light$ xauth nlist "${HOST}:0" | rsh dark.matt.er xauth nmerge - </verb></tscreen> <enum> <item> Extraire le cookie de votre fichier local <tt>˜/.Xauthority</tt> (<tt/xauth nlist :0/). <item> Le transférer vers dark.matt.er (<tt/| rsh dark.matt.er/). <item> >Le mettre dans <tt>˜/.Xauthority</tt> là (<tt/xauth nmerge -/). </enum> Notez l'utilisation de <tt/${HOST}/. Vous devez transférer le cookie qui est explicitement associé à l'hôte local. Une application X distante interpréterait une valeur d'unité d'affichage égale à <tt/:0/ comme étant une référence à la machine distante, ce qui ne correspond pas à ce que l'on veut ! <sect3> Manuellement, par Telnet Il est possible que <tt>rsh</tt> ne fonctionne pas chez vous. En plus de cela, <tt>rsh</tt> a un inconvénient en ce qui concerne la sécurité (noms d'hôtes parodiés, si je me souviens bien). Si vous ne pouvez, ou ne voulez, pas utiliser <tt>rsh</tt>, vous pouvez également transférer le cookie manuellement, comme ceci : <tscreen><verb> light$ echo $DISPLAY :0 light$ xauth list $DISPLAY light/unix:0 MIT-MAGIC-COOKIE-1 076aaecfd370fd2af6bb9f5550b26926 light$ rlogin dark.matt.er Password: dark% setenv DISPLAY light.uni.verse:0 dark% xauth Using authority file /home/zweije/.Xauthority xauth> add light.uni.verse:0 . 076aaecfd370fd2af6bb9f5550b26926 xauth> exit Writing authority file /home/zweije/.Xauthority dark% xfig & [15332] dark% logout light$ </verb></tscreen> Consultez également rsh(1) et xauth(1x) pour de plus amples informations. <sect3> En automatisant la méthode Telnet Il doit être possible de superposer le cookie sur la variable <tt/TERM/ ou <tt/DISPLAY/ quand vous utilisez telnet sur l'hôte éloigné. Cela doit fonctionner de la même manière que de superposer la variable <tt/DISPLAY/ sur la variable <tt/TERM/. Regardez la section 5 : Dire au Client. De mon point de vue, sur ce sujet, vous prenez vos responsabilités, mais cela m'intéresse si quelqu'un peut me confirmer ou m'infirmer cela. Notez, cependant, qu'avec certains Unix les variables d'environnement peuvent être visibles par les autres et que que vous ne puissiez pas empêcher la visualisation du cookie dans <tt/$TERM/ si certains veulent le voir. <sect2> Utilisation du Cookie Une application X, telle que <tt>xfig</tt> ci-dessus, sur <tt>dark.matt.er</tt>, ira automatiquement voir le cookie dans <tt>˜/.Xauthority</tt> pour s'authentifier. L'utilisation de <tt/localhost:D/ entraîne une petite difficulté. Les applications X clientes traduisent <tt/localhost:D/ en <tt>host/unix:D</tt> pour effectuer la recherche du cookie. Effectivement, cela signifie qu'un cookie pour <tt/localhost:D/ dans votre <tt>~/.Xauthority</tt> n'a <em/aucun/ effet. Si l'on y réfléchi, c'est logique. L'interprétation de <tt/localhost/ dépend entièrement de la machine sur laquelle s'effectue cette interprétation. Si ce n'était pas le cas, cela causerait un horrible bazar dans le cas d'un répertoire personnel (home) partagé, par exemple par l'intermédiaire de NFS, avec plusieurs hôtes interférants chacun avec ses propres cookies. <sect1> Ssh Les enregistrements d'autorisation sont transmis sur le réseau sans codage. Si vous vous souciez de ce que l'on puisse espionner vos connexions, utilisez ssh, le shell sécurisé. Il effectuera des transmissions X sécurisées au moyen de connexions cryptées. De plus, il est génial pour d'autres choses aussi. C'est une bonne amélioration structurelle de votre système. Allez simplement voir <htmlurl url="http://www.ssh.org/" name="http://www.ssh.org/">, la page d'accueil de ssh. Qui possède d'autres informations sur les méthodes d'authentification ou de cryptage des connexions X ? Peut-être Kerberos ? <sect> Les applications X avec un identificateur d'utilisateur (User-id) différent Supposez que vous vouliez faire tourner un outil graphique de configuration qui nécessite d'avoir les privilèges du compte root alors que la session X actuelle se déroule sous votre compte. Cela peut sembler étrange au premier abord, mais le serveur X <em/ne/ permettra <em/pas/ à cet outil d'accéder à votre unité d'affichage. Comment cela est-il possible alors que <em/root/ peut normalement tout faire ? Et comment contourner ce problème ? Élargissons le propos au cas où l'on veut faire tourner une application X, sous un identificateur d'utilisateur <tt/clientuser/, alors que la session X a été lancée par <tt/serveruser/. Si vous avez lu le paragraphe sur les <em/cookies/, il est évident que <tt/clientuser/ ne peut pas accéder à votre unité d'affichage : <tt>~clientuser/.Xauthority</tt> ne contient le cookie magique qui permet d'accéder à l'unité d'affichage. Le cookie correct se trouve dans <tt>~serveruser/.Xauthority</tt>. <sect1> Plusieurs utilisateurs sur le même hôte Naturellement, tout ce qui marche pour un X distant marchera aussi pour un X à partir d'un identificateur d'utilisateur différent (particulièrement <tt/slogin localhost -l clientuser/). Et ici l'hôte client et l'hôte serveur sont précisément les mêmes. Cependant, quand les deux hôtes sont les mêmes, il y a quelques raccourcis pour transférer le <em/cookie magique/. On supposera que l'on utilise <tt/su/ pour passer d'un identificateur utilisateur à l'autre. Essentiellement, il faut écrire un script qui appelle <tt/su/, mais enveloppe la commande que <tt/su/ exécute d'un peu de code qui effectue les tâches nécessaires pour le X distant. Ces tâches nécessaires sont l'initialisation de la variable <tt/DISPLAY/ et le transfert du <em/cookie magique/. L'initialisation de <tt/DISPLAY/ est relativement facile ; il faut simplement définir <tt/DISPLAY="$DISPLAY"/ avant d'exécuter l'argument de la commande su. Donc, il faut simplement faire : <tscreen><verb> su - clientuser -c "env DISPLAY="$DISPLAY" clientprogram &" </verb></tscreen> Ce n'est pas tout, il faut encore transférer le cookie. On peut le retrouver en utilisant <tt/xauth list "$DISPLAY"/. Cette commande renvoie le cookie dans un format qui convient pour l'utiliser dans la commande <tt/xauth add/; ce dont nous avons justement besoin ! On pourrait imaginer le passer le cookie par l'intermédiaire d'un canal de transmission. Manque de chance, ce n'est pas si facile de passer quelque chose à la commande <tt/su/ par l'intermédiaire d'un canal de transmission car <tt/su/ attends le mot de passe de l'entrée standard. Cependant, dans un script shell on peut jongler avec quelques descripteurs de fichiers et arriver à le faire. Donc, on écrit un script de ce style en le paramétrant avec <tt/clientuser/ et <tt/clientprogram/. Pendant que nous y sommes, améliorons un peu ce script, ça va le rendre un peu moins compréhensible mais un peu plus robuste. Le tout ressemble à cela : <tscreen><verb> #!/bin/sh if [ $# -lt 2 ] then echo "usage: `basename $0` clientuser command" >&2 exit 2 fi CLIENTUSER="$1" shift # FD 4 becomes stdin too exec 4>&0 xauth list "$DISPLAY" | sed -e 's/^/add /' | { # FD 3 becomes xauth output # FD 0 becomes stdin again # FD 4 is closed exec 3>&0 0>&4 4>&- exec su - "$CLIENTUSER" -c \ "xauth -q <&3 exec env DISPLAY='$DISPLAY' "'"$SHELL"'" -c '$*' 3>&-" } </verb></tscreen> Je pense que c'est portable et que cela fonctionne suffisamment correctement dans la plupart des circonstances. Le seul défaut auquel je pense en ce moment est dû à l'utilisation de <tt/'$*'/, les guillemets simples dans <tt/command/ vont perturber les guillemets de l'argument(<tt/'$*'/) de la commande <tt/su/. Si cela entraîne quelque chose de vraiment gênant, envoyez-moi un courrier électronique. Nommez le script <tt>/usr/local/bin/xsu</tt>, et vous pouvez faire : <tscreen><verb> xsu clientuser 'command &' </verb></tscreen> Cela ne peut pas être plus facile, à moins que vous ne vous débarrassiez du mot de passe. Oui, il existe des moyens pour y arriver (<tt/sudo/), mais ce n'est pas l'endroit pour en parler. <sect1> Root est l'utilisateur client Évidemment, tout ce qui marche pour un client non root doit fonctionner pour root. Cependant, avec root vous pouvez faire cela encore plus facilement, car celui-ci peut lire le fichier <tt>~/.Xauthority</tt> de tout le monde. Il n'y a pas besoin de transférer le cookie. Tout ce qu'il y a à faire consiste à initialiser <tt/DISPLAY/, et à faire pointer <tt/XAUTHORITY/ sur <tt>~serveruser/.Xauthority</tt>. Donc, vous pouvez écrire : <tscreen><verb> su - -c "exec env DISPLAY='$DISPLAY' \ XAUTHORITY='${XAUTHORITY-$HOME/.Xauthority}' \ command" </verb></tscreen> Et, en mettant cela dans un script, cela donne quelque chose comme <tscreen><verb> #!/bin/sh if [ $# -lt 1 ] then echo "usage: `basename $0` command" >&2 exit 2 fi su - -c "exec env DISPLAY='$DISPLAY' \ XAUTHORITY='${XAUTHORITY-$HOME/.Xauthority}' \ "'"$SHELL"'" -c '$*'" </verb></tscreen> Nommez le script <tt>/usr/local/bin/xroot</tt>, et vous pouvez faire : <tscreen><verb> xroot 'control-panel &' </verb></tscreen> Cependant, si vous avez déjà initialisé <tt/xsu/ , il n'y a pas de vrai raison de faire cela. <sect> Faire tourner un gestionnaire de fenêtres distant Un gestionnaire de fenêtres (comme <tt/twm/, <tt/wmaker/, ou <tt/fvwm95/) est une application comme n'importe quelle autre. La procédure normale devrait fonctionner. Enfin, presque. Il ne peut tourner, au plus, qu'un seul gestionnaire de fenêtres à un instant donné dans une unité d'affichage. Si vous faites déjà tourner un gestionnaire de fenêtre local, vous ne pouvez pas lancer le gestionnaire distant (il le dira et s'arrêtera). Il faut tuer (ou simplement quitter) le gestionnaire local en premier. Par manque de chance, beaucoup de scripts de sessions X se terminent par un <tscreen><verb> exec le-gestionnaire-de-fenetre-de-votre-choix </verb></tscreen> et cela signifie que quand le gestionnaire de fenêtre (local) se termine, votre session se termine, et le système (xdm ou xinit) considère que votre session est terminée, et effectivement, vous déconnecte. Vous aurez encore à faire quelques contorsions, mais vous devez y arriver et ce n'est pas trop difficile. Amusez-vous un peu avec votre script de session (normalement <tt>~/.xsession</tt> ou <tt>~/.xinitrc</tt>) pour arriver à vos fins. Attention, un gestionnaire de fenêtres permet souvent de faire tourner de nouveaux programmes qui s'exécuteront sur la machine locale. C'est-à-dire locale à la machine sur lequel tourne le gestionnaire de fenêtres. Si vous faites tourner un gestionnaire de fenêtres distant, il lancera des applications distantes, et ce n'est peut-être pas ce que vous voulez. Naturellement, elles continueront à s'afficher sur l'unité d'affichage qui est locale pour vous. <sect> Maintenance D'ordinaire, la première fois que vous allez essayer de faire tourner une application X à distance, ça ne marchera pas. Voici quelques-uns des messages d'erreur habituels, leur cause probable et des solutions pour vous aider à progresser. <tscreen><verb> xterm Xt error: Can't open display: </verb></tscreen> Il n'y a pas de variable DISPLAY renseignée dans votre environnement et vous n'avez pas non plus lancé l'application avec le drapeau <tt>-display</tt>. L'application assume que la variable display contient une chaîne de caractères vide, ce qui est syntaxiquement incorrect. La solution à cela consiste à s'assurer que la variable DISPLAY est correctement renseignée dans l'environnement (avec <tt>setenv</tt> ou <tt>export</tt> selon votre shell). <tscreen><verb> _X11TransSocketINETConnect: Can't connect: errno = 101 xterm Xt error: Can't open display: love.dial.xs4all.nl:0 </verb></tscreen> Erreur 101 signifie ``Réseau inaccessible''. L'application n'arrive pas à se connecter au serveur à travers le réseau. Vérifiez que la variable <tt/DISPLAY/ est correctement renseignée et que la machine serveur est accessible à partir de votre client (ce qui devrait être le cas, car après tout vous êtes probablement connecté au serveur en ayant une session telnet avec votre client). <tscreen><verb> _X11TransSocketINETConnect: Can't connect: errno = 111 xterm Xt error: Can't open display: love.dial.xs4all.nl:0 </verb></tscreen> Erreur 111 signifie ``Connexion refusée''. La machine à laquelle vous êtes en train d'essayer de vous connecter peut être atteinte, mais le serveur indiqué n'existe pas à cet endroit. Vérifiez que vous utilisez le nom d'hôte correct et le numéro d'unité d'affichage adéquat. <tscreen><verb> Xlib: connection to ":0.0" refused by server Xlib: Client is not authorized to connect to Server xterm Xt error: Can't open display: love.dial.xs4all.nl:0.0 </verb></tscreen> Le client pourrait réaliser une connexion avec le serveur, mais celui-ci ne permet pas au client de l'utiliser (pas autorisé). Assurez-vous que vous avez transféré le bon cookie au client, et qu'il n'est pas périmé (le serveur utilise un nouveau cookie au démarrage d'une nouvelle session). </article>