Ce petit guide constitue un guide sur la mani�re de faire tourner des applications X � distance. J'ai r�dig� ce document pour plusieurs raisons :
xhost +hostname » ou m�me de
« xhost + » pour r�aliser des connexions
X. C'est d'une ins�curit� totale, et il existe de bien
meilleures m�thodes ;
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 propre syst�me.
La version (anglaise) la plus r�cente de ce document est toujours disponible sur le WWW � http://www.xs4all.nl/~zweije/xauth.html. Il est �galement disponible en tant que mini-HOWTO Linux « Applications X � distance » (Remote X Apps) � : http://www.tldp.org/HOWTO/mini/Remote-X-Apps. Les (mini-)HOWTO du projet de documentation Linux (LDP) sont disponibles par http ou ftp sur www.tldp.org.
La version fran�aise la plus r�cente de ce document est toujours disponible sur le site du projet traduc.org � http://www.traduc.org/docs/HOWTO/mini/lecture/Remote-X-Apps.html.
Ceci constitue la version 0.7.5. Aucune garantie, seulement de bonnes intentions. Je suis ouvert aux suggestions, id�es, ajouts, pointeurs utiles, corrections (typo), et c�tera. Je veux que cela reste un document simple et lisible, dans la bonne moyenne du style des guides pratiques du projet de documentation Linux. Les querelles seront redirig�es vers /dev/null. Ce document est diffus� sous la version 1.1 de la licence GNU Free Documentation Licence. This document is released under version 1.1 of the GNU Free Documentation Licence.
Le contenu de ce petit guide a �t� mis � jour le 8 d�cembre 2001 par Vincent Zweije. La version fran�aise de ce document a �t� mise � jour le 4 mars 2003 par Fr�d�ric Bothamy. La relecture de cette nouvelle version fran�aise a �t� r�alis�e par Olivier Kaloudoff.
Un document, en rapport avec cela, sur le WWW traite de « Que faire quand Tk dit que votre �cran n'est pas s�r », http://ce-toolkit.crd.ge.com/tkxauth/. Il a �t� �crit par 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 de la s�rie consacr�e au syst�me X Window, le « Guide de l'administrateur du syst�me X Window » de chez O'Reilly and Associates �tait une bonne source d'informations. Cependant, ce guide n'a pas �t� mis � jour depuis sa publication d'origine en 1992. Il ne couvre donc que X11R4 et X11R5, tout ce qui est sp�cifique � X11R6 n'est pas couvert.
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 � http://ciac.llnl.gov/ciac/documents/ciac2316.html.
Consultez �galement les forums de diffusion Usenet, tels que :
comp.windows.x,
comp.os.linux.x et comp.os.linux.networking.
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 http://www.vigor.nu/dxpc/ ou LBX http://www.traduc.org/docs/HOWTO/mini/lecture/LBX.html (disponible en version originale sur le site de l'auteur : http://www.paulandlesley.org/faqs/LBX-HOWTO.html).
Vous avez deux choses � faire pour r�aliser tout cela :
Le mot magique est DISPLAY (unit� d'affichage). 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 fournit 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 :
DISPLAY=light.uni.verse:0
DISPLAY=localhost:4
DISPLAY=:0
Un nom d'unit� d'affichage est constitu� d'un nom d'h�te (par exemple :
light.uni.verse et localhost), du signe deux point
(:), et d'un num�ro de s�quence (tels que 0 et
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
.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
n=0, et c'est le num�ro par d�faut.
D'autres formes de DISPLAY existent, mais celle-ci suffira
pour notre propos.
Pour celui qui est curieux de technique :
hostname:D.S signifie �cran S sur unit� d'affichage
D de l'h�te hostname : le serveur X de cette unit�
d'affichage est � l'�coute du port TCP 6000+D.
host/unix:D.S signifie �cran S sur unit� d'affichage
D de l'h�te host : le serveur X de cette unit� d'affichage
est � l'�coute du socket de domaine UNIX /tmp/.X11-unix/XD
(et donc, seul host peut l'atteindre).
:D.S est �quivalent � host/unix:D.S, o� host
est le nom de l'h�te local.
Le programme client (par exemple, votre application graphique)
sait � quelle unit� d'affichage il doit se connecter en consultant la
variable d'environnement DISPLAY. Cependant ce param�trage peut �tre
modifi� en lan�ant le client avec l'argument -display
hostname:0 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 light.uni.verse:0.
Nous voulons faire tourner le programme de dessin xfig
sur un ordinateur � distance, appel�
dark.matt.er,
et afficher sa sortie ici, sur light.
Supposons que vous vous soyez d�j� connect� par telnet � l'ordinateur distant,
dark.matt.er.
Si l'interpr�teur de commande de l'ordinateur �loign� est csh :
dark% setenv DISPLAY light.uni.verse:0
dark% xfig &
Ou, d'une autre mani�re :
dark% xfig -display light.uni.verse:0 &
Si c'est sh qui tourne sur l'ordinateur � distance :
dark$ DISPLAY=light.uni.verse:0
dark$ export DISPLAY
dark$ xfig &
Ou, autrement :
dark$ DISPLAY=light.uni.verse:0 xfig &
Ou, bien s�r, �galement :
dark$ xfig -display light.uni.verse:0 &
Il para�t que certaines versions de telnet transmettent automatiquement la
variable
DISPLAY
� l'ordinateur h�te �loign�. Si vous avez l'une de 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 TERM, et avec un bidouillage judicieux, il est
possible de superposer la variable
DISPLAY
sur la variable TERM.
L'id�e, sous-jacente � cette superposition, est de r�aliser une sorte de script
pour effectuer ceci : avant la connexion par telnet, donnez la valeur de
DISPLAY � TERM. Puis, lancez telnet. Du c�t� de l'ordinateur
distant, dans le fichier .*shrc concern�, lisez la valeur de
DISPLAY � partir de TERM.
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.
Veuillez noter que certains serveurs X (de XFree86) peuvent �tre configur�s
pour ne pas �couter sur le port habituel TCP avec le param�tre
-nolisten tcp. La configuration par d�faut de Debian GNU/Linux,
notamment, d�sactive l'�coute sur le port TCP par le serveur X. Si vous
d�sirez utiliser X � distance sur un syst�me Debian, vous devriez r�activer
ceci en modifiant la fa�on dont est lanc� le serveur X. Veuillez voir le
fichier /etc/X11/xinit/xserverrc pour un point de d�part.
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
xhost.
Pour utiliser ce m�canisme dans l'exemple pr�c�dent, faites :
light$ xhost +dark.matt.er
Ceci permet toutes les connexions � partir de l'h�te dark.matt.er.
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 :
light$ xhost -dark.matt.er
Vous pouvez d�sactiver la v�rification des h�tes avec :
light$ xhost +
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 :
light$ xhost -
xhost -
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).
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
ensemble dans ~/.Xauthority. Votre fichier
~/.Xauthority doit �tre inaccessible pour les utilisateurs
groupe/autres. Le programme xauth g�re ces cookies, d'o� le surnom xauth dans
ce sch�ma.
Vous pouvez sp�cifier un fichier cookie diff�rent avec la variable
d'environnement XAUTHORITY, mais vous aurez rarement besoin de le
faire. Si vous ne savez pas quel fichier cookie votre xauth utilise, faites
un xauth -v et il vous l'indiquera.
Au d�marrage d'une session, le serveur lit un cookie dans le fichier qui est
indiqu� par l'argument -auth. Ensuite, le serveur ne permet la
connexion que des clients qui connaissent le m�me cookie. Quand le
cookie dans ~/.Xauthority
change, 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 ~/.Xauthority
� moins qu'un client ne les y mettent. Selon David Wiggins :
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.
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.
Si vous voulez utiliser xauth, vous devez lancer le serveur X avec
l'argument -auth authfile. Si vous utilisez le script
startx 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 /usr/X11R6/bin/startx :
mcookie|sed -e 's/^/add :0 . /'|xauth -q
xinit -- -auth "$HOME/.Xauthority"
Mcookie est un petit programme du paquet util-linux, site primaire
ftp://ftp.win.tue.nl/pub/linux-local/utils/util-linux.
Autrement, vous pouvez utiliser md5sum pour cr�er quelques donn�es
al�atoires (de, par exemple, /dev/urandom ou ps -axl) au
format cookie :
dd if=/dev/urandom count=1|md5sum|sed -e 's/^/add :0 . /'|xauth -q
xinit -- -auth "$HOME/.Xauthority"
Si vous ne pouvez pas �diter le script startx (parce que vous n'�tes pas root),
demandez � votre administrateur 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 ~/.xserverrc. 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 ~/.xserverrc le
mcookie de la ligne ci-dessus pour cr�er un cookie puis lancer le
v�ritable serveur X :
#!/bin/sh
mcookie|sed -e 's/^/add :0 . /'|xauth -q
exec /usr/X11R6/bin/X "$@" -auth "$HOME/.Xauthority"
Si vous utilisez xdm pour g�rer vos sessions X, vous pouvez
utiliser xauth facilement. D�finissez les ressources du
DisplayManager.authDir dans /etc/X11/xdm/xdm-config.
Xdm passera l'argument -auth au serveur X � son d�marrage. Au moment de
la connexion sous xdm, xdm place le cookie dans
~/.Xauthority pour vous. Consultez xdm(1) pour de plus
amples informations.
Par exemple, mon /etc/X11/xdm/xdm-config
contient la ligne suivante :
DisplayManager.authDir: /var/lib/xdm
Maintenant que vous avez lanc� votre session X sur le serveur h�te
light.uni.verse et que vous avez votre cookie dans
~/.Xauthority, il vous faut transf�rer le cookie sur
le client, dark.matt.er. Il y a plusieurs fa�ons de le faire.
Le plus simple est que vos r�pertoires sur light et dark
soient partag�s. Les fichiers ~/.Xauthority 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 :0
dans ~/.Xauthority, 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, :0 et light:0 avec un peu d'astuce :
#!/bin/sh
mcookie|sed -e 's/^/add :0 . /' -e p -e "s/:/$HOST&/"|xauth -q
exec /usr/X11R6/bin/X "$@" -auth "$HOME/.Xauthority"
rshSi les r�pertoires home ne sont pas partag�s, vous pouvez transf�rer le cookie au moyen de rsh, le shell � distance :
light$ xauth nlist "${HOST}:0" | rsh dark.matt.er xauth nmerge -
~/.Xauthority
(xauth nlist :0).
| rsh dark.matt.er).
~/.Xauthority l� (xauth nmerge -).
Notez l'utilisation de ${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 � :0 comme
�tant une r�f�rence � la machine distante, ce qui ne correspond pas � ce
que l'on veut !
Il est possible que rsh ne fonctionne pas chez vous. En plus de
cela, rsh a un inconv�nient en ce qui concerne la s�curit�
(noms d'h�tes usurp�s, si je me souviens bien). Si vous ne pouvez, ou ne
voulez, pas utiliser rsh, vous pouvez �galement transf�rer le
cookie manuellement, comme ceci :
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$
Consultez �galement rsh(1) et xauth(1x) pour de plus amples informations.
Il doit �tre possible de superposer le cookie sur la
variable TERM ou DISPLAY quand vous utilisez telnet sur l'h�te
�loign�. Cela doit fonctionner de la m�me mani�re que de superposer la
variable DISPLAY sur la variable 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 vous ne pourrez pas emp�cher la
visualisation du cookie dans $TERM si certains veulent le voir.
Une application X, telle que xfig ci-dessus, sur
dark.matt.er, ira automatiquement voir le cookie dans
~/.Xauthority pour s'authentifier.
L'utilisation de localhost:D entra�ne une petite difficult�.
Les applications X clientes traduisent localhost:D en
host/unix:D pour effectuer la recherche du cookie.
Effectivement, cela signifie qu'un cookie pour localhost:D dans
votre ~/.Xauthority n'a aucun effet.
Si l'on y r�fl�chit, c'est logique. L'interpr�tation de 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�rant chacun avec ses propres cookies.
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 chiffr�es.
Pour activer la transmission X par ssh, utilisez l'option de la ligne de
commande -X ou �crivez ce qui suit dans votre fichier local de
configuration de ssh :
Host remote.host.name
ForwardX11 yes
Le serveur ssh (sshd) du c�t� distant positionnera automatiquement la
variable DISPLAY sur l'extr�mit� du tunnel X transmis. Le tunnel
distant r�cup�re son propre cookie ; le serveur ssh distant le g�n�re
pour vous et le place dans ~/.Xauthority l�-bas. Ainsi,
l'autorisation X avec ssh est compl�tement automatique.
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 http://www.ssh.org/, la page d'accueil de ssh.
Si vous poss�dez d'autres informations sur les m�thodes d'authentification ou de chiffrement des connexions X, par exemple, gr�ce � Kerberos, envoyez-les moi, je les int�grerai ici.
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 ne permettra pas � cet outil d'acc�der � votre unit� d'affichage. Comment cela est-il possible alors que 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 clientuser, alors que la session
X a �t� lanc�e par serveruser. Si vous avez lu le paragraphe sur les
cookies, il est �vident que clientuser ne peut pas acc�der �
votre unit� d'affichage :
~clientuser/.Xauthority ne contient pas le cookie magique qui permet
d'acc�der � l'unit� d'affichage. Le cookie correct se trouve dans
~serveruser/.Xauthority.
Naturellement, tout ce qui marche pour un X distant marchera aussi pour
un X � partir d'un identificateur d'utilisateur diff�rent (particuli�rement
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
cookie magique.
On supposera que l'on utilise su pour passer d'un identificateur
utilisateur � l'autre. Essentiellement, il faut �crire un script qui
appelle su, mais enveloppe la commande que 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 DISPLAY
et le transfert du cookie magique.
L'initialisation de DISPLAY est relativement facile ; il faut
simplement d�finir
DISPLAY="$DISPLAY" avant d'ex�cuter l'argument de la commande su. Donc,
il faut simplement faire :
su - clientuser -c "env DISPLAY="$DISPLAY" clientprogram &"
Ce n'est pas tout, il faut encore transf�rer le cookie. On peut le retrouver
en utilisant xauth list "$DISPLAY". Cette commande renvoie le
cookie dans un format qui convient pour l'utiliser dans la commande
xauth add : ce dont
nous avons justement besoin !
On pourrait imaginer 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 su par l'interm�diaire d'un canal de transmission car su
attend 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 clientuser et
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 :
#!/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>&-"
}
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 '$*', les guillemets simples dans
command vont perturber les guillemets de l'argument('$*')
de la commande su. Si cela entra�ne quelque chose de vraiment g�nant,
envoyez-moi un courrier �lectronique.
Nommez le script /usr/local/bin/xsu, et vous pouvez faire :
xsu clientuser 'command &'
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 (sudo), mais
ce n'est pas l'endroit pour en parler.
Le petit script xsu mentionn� ci-dessus a servi comme base pour un
script plus �tendu appel� sux qui a, apparemment, trouv� sa place
comme paquet dans la distribution
Debian.
�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 ~/.Xauthority de
tout le monde. Il n'y a pas besoin de transf�rer le cookie. Tout ce
qu'il y a � faire consiste � initialiser DISPLAY, et � faire pointer
XAUTHORITY sur ~serveruser/.Xauthority. Donc, vous
pouvez �crire :
su - -c "exec env DISPLAY='$DISPLAY' \
XAUTHORITY='${XAUTHORITY-$HOME/.Xauthority}' \
command"
Et, en mettant cela dans un script, cela donne quelque chose comme
#!/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 '$*'"
Nommez le script /usr/local/bin/xroot, et vous pouvez faire :
xroot 'control-panel &'
Cependant, si vous avez d�j� initialis� xsu , il n'y a pas de vraie
raison de faire cela.
Un gestionnaire de fen�tres (comme twm, wmaker, ou 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
exec le-gestionnaire-de-fenetres-de-votre-choix
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 ~/.xsession ou
~/.xinitrc) 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.
Trouvez une utilisation � votre vieux PC ! Faites-en un endroit suppl�mentaire pour pouvoir travailler ! Pas besoin d'acheter un nouveau mat�riel co�teux ! Vous avez d�j� tout ce qu'il faut !
S�rieusement, vous pouvez mettre en place un vieux PC comme terminal X. Un terminal X est un ordinateur qui fondamentalement n'ex�cute rien d'autre qu'un serveur X. Vous pouvez vous connecter dessus et obtenir une session X, avec des xterms, xbiff, xclock et tout autre client X concevable. Cependant, les clients X s'ex�cuteront sur l'h�te distant et ils utiliseront le serveur X distant pour afficher leur sortie sur votre terminal X local. M�me le gestionnaire de fen�tre s'ex�cutera � distance.
Un terminal X consomme peu de ressources en comparaison d'une machine Unix compl�te. J'ai ici un terminal X constitu� par un processeur 486, 16 Mo de RAM et 250 Mo d'espace disque. Oh et une connexion r�seau, naturellement. Il n'a m�me pas besoin d'avoir des r�pertoires utilisateurs.
Pour trouver des lectures li�es � ce sujet, jetez un coup d'oeil aux documents suivants :
� la diff�rence des documents ci-dessus, le document que vous �tes en train de lire se limite � une courte description de XDMCP, mais il insiste plus sur les probl�mes de s�curit� impliqu�s.
En ce qui concerne X, le terminal X va n'ex�cuter rien d'autre qu'un serveur X. Ce serveur X sera configur� pour dialoguer avec l'h�te distant en utilisant XDMCP (le protocole de contr�le de gestion d'affichage X, � X Display Manager Control Protocol �). Il va demander � l'h�te distant une session X. L'h�te distant fournira une fen�tre de connexion dans le terminal X et apr�s la connexion, il ex�cutera une session X avec tout l'habillage y compris le gestionnaire de fen�tres, tout cela utilisant X distant pour l'affichage sur le terminal X.
Vous aurez probablement remarqu� que l'h�te distant agit comme un serveur, bien que pas comme un serveur X. L'h�te distant fournit les sessions X aux serveurs X qui les demandent. Ainsi, selon XDMCP, l'h�te distant est en fait un serveur, fournissant des sessions X, �galement connu sous le nom de serveur XDMCP. Le serveur X joue le r�le d'un client XDMCP ! Vous me suivez ?
Le programme qui fournit le service XDMCP sur le serveur XDMCP est
xdm. Donc, pour ex�cuter un terminal X, vous devez configurer deux
programmes : X (le client XDMCP) sur le terminal X et xdm (le
serveur XDMCP) sur l'h�te distant.
Vous devez toujours vous rappeler que le protocole X (et le protocole XDMCP) n'est pas chiffr�. Si vous devez utiliser X � distance, tout ce qui transite sur le r�seau peut �tre espionn� par d'autres h�tes du r�seau. Ceci est particuli�rement n�faste avec les sessions X distantes car la premi�re chose qui se passe est la connexion en donnant l'utilisateur et le mot de passe. Vous ne devez donc ex�cuter X � distance que sur un r�seau s�curis� !
X comme client XDMCP
Si vous d�sirez mettre en place une machine Linux comme terminal X, vous avez besoin de tr�s peu de ressources. Fondamentalement, vous avez besoin de ce qu'il est n�cessaire d'avoir pour faire fonctionner une machine Linux d�pouill�e plus un serveur X. Sp�cifiquement, vous n'avez pas besoin des clients et biblioth�ques X. Il peut �tre utile d'installer certaines polices X, mais vous pouvez �galement utiliser un serveur de polices situ� quelque part sur le r�seau.
Il existe plusieurs moyens pour un serveur X d'obtenir une session X d'un serveur XDMCP. La plus simple est d'aller directement � un serveur XDMCP connu et de lui en demander une. Le serveur peut �galement �mettre en multi-diffusion une requ�te et utiliser le premier serveur XDMCP qui r�pond. Enfin, le serveur X peut demander � un serveur XDMCP de lui fournir une liste des h�tes qui acceptent de fournir une session et laisser l'utilisateur choisir l'h�te de session.
X -query sessionhost
xdm fonctionne sur sessionhost, vous
obtiendrez une fen�tre de connexion et, apr�s connexion, une session X.
X -broadcast
xdm fonctionne sur un h�te quelque part sur le
r�seau, vous obtiendrez une fen�tre de connexion du premier (et, on
l'esp�re, du plus rapide) xdm qui r�pond et, apr�s connexion, une
session X.
X -indirect xdmcpserver
xdm est bien configur� sur ce serveur, une liste
des h�tes vous sera pr�sent�e parmi lesquels vous pourrez choisir.
Choisissez-en un ; vous obtiendrez la fen�tre de connexion pour cet
h�te et, apr�s connexion, la session que vous avez demand�e.
Il se peut que vous ayez remarqu� l'absence de l'option -auth. Le
serveur X utilisera XDMCP pour n�gocier le mot de passe secret
(� magic cookie �) avec le serveur XDMCP. Le serveur XDMCP
placera le cookie dans votre ~/.Xauthority apr�s la connexion.
Apr�s la fermeture d'une session, le serveur X va boucler, il reviendra au
serveur XDMCP d'origine et lui demandera une nouvelle session (ou une liste
de choix). Si vous ne d�sirez pas cela, vous pouvez utiliser l'option
-once. Notez que ceci ne semble pas fonctionner avec l'option
-indirect � cause de l'impl�mentation du � chooser �.
Quand vous avez d�termin� la fa�on dont vous allez ex�cuter le serveur X,
vous pouvez alors le placer dans un script de d�marrage ou m�me l'ex�cuter
directement � partir de /etc/inittab. Veuillez consulter la
documentation de votre propre distribution pour savoir comment modifier vos
scripts d'amor�age ou /etc/inittab.
N'ex�cutez pas un serveur X ainsi depuis le fichier de configuration
Xservers. xdm s'attend � pouvoir se connecter � de tels serveurs
et il pourrait les tuer s'il ne peut pas se connecter.
xdm comme serveur XDMCP
Le programme qui fournit le service XDMCP (le service de session) est
g�n�ralement xdm. Il existe des variantes de celui-ci, comme wdm
ou gdm sur Linux, mais ceux-ci fonctionnent fondamentalement de la
m�me fa�on. Assurez-vous donc que xdm ou une variante est install� sur
l'h�te o� vous d�sirez ex�cuter vos sessions X. Si vous disposez d'une
connexion graphique locale depuis l'h�te de session X, xdm est d�j�
install� ; la plupart des distributions Linux sont ainsi fournis de
nos jours.
En plus de xdm, vous aurez besoin des programmes que vous d�sirez
ex�cuter dans une session X. C'est-�-dire, tous les clients X comme
xterm, xfig, xclock, des gestionnaires de fen�tre et ainsi
de suite. Cependant, pour un serveur XDMCP, vous n'avez pas besoin
d'installer de serveur X ; le serveur X fonctionnera � la place sur le
terminal X.
� partir de l'histoire sur le serveur X ci-dessus, vous pouvez en conclure qu'il y a fondamentalement deux types de services XDMCP. Il y a le service direct qui consiste � permettre la connexion d'un client XDMCP et � lui fournir une session X. Il y a �galement le service indirect dans lequel le serveur fournit une liste d'h�tes fournissant un service direct, au choix pour le client XDMCP.
Tous les services xdm sont configur�s dans le fichier d'acc�s,
g�n�ralement situ� � /etc/X11/xdm/Xaccess ou un emplacement
semblable. Cet emplacement est en fait d�fini dans le fichier de
configuration g�n�ral de xdm /etc/X11/xdm/xdm-config par la
ressource accessFile. Veuillez voir votre manuel xdm pour
l'emplacement par d�faut.
Si vous d�sirez autoriser xdm � fournir des sessions X aux clients
XDMCP, que ce soit par multi-diffusion ou non, placez le nom d'h�te du
client XDMCP (le serveur X, vous vous souvenez ?) seul sur une ligne
dans le fichier Xaccess. En fait, vous pouvez placer un expression
rationnelle correspondant � plusieurs h�tes. Voici quelques expressions
valides :
xterm023.my.domain # xterm023.my.domain peut obtenir une session X
*.my.domain # tout h�te dans my.domain peut obtenir une session X
* # tout h�te sur Internet peut obtenir une session X (non s�curis�)
Vouloir fournir une session X � tout h�te sur Internet est discutable. De fa�on �vidente, tout service que vous fournissez est une faille de s�curit� potentielle dans la s�curit� de votre serveur. D'un autre c�t�, le serveur devrait �tre s�curis� lui-m�me et un client XDMCP demandant une session X doit fournir une authentification valide avant que la session X ne soit accord�e.
De plus, la session X utilise une connexion X distante qui n'est pas chiffr�e. La paire nom d'utilisateur/mot de passe de connexion sera transport�e sur cette connexion. Toute personne pourrait alors espionner des combinaisons valides d'utilisateur/mot de passe tout comme sur des connexions telnet simple. Ceci est m�me pire que d'avoir son mot de passe secret (� magic cookie �) espionn�.
Prenez vos propres d�cisions ici, mais je recommande de ne pas activer ce service au monde entier � moins d'avoir une bonne raison.
Si vous d�sirez fournir aux clients XDMCP (X -indirect xdmcpserver)
une liste de choix (une liste d'h�tes pour choisir duquel ils obtiendront
une session X), faite suivre l'expression rationnelle du client par le
mot-cl� CHOOSER et la liste des h�tes que le client peut choisir. � la
place de la liste des h�tes, vous pouvez �galement sp�cifier
BROADCAST ; avec ceci, xdm �met en multi-diffusion sur le
r�seau pour interroger les serveurs d�sirant fournir une session. Des
exemples valides :
xterm023.my.domain CHOOSER seshost1 seshost2
*.my.domain CHOOSER BROADCAST
* CHOOSER extseshost1 extseshost2
xterm023 de choisir entre des sessions sur
seshost1 et sur seshost2. Le deuxi�me exemple permet � tout h�te
dans my.domain de choisir n'importe quel h�te fournissant une session
X. Le troisi�me exemple permet � tout h�te de choisir une session entre
extseshost1 et extseshost2.
Ce n'est probablement pas une bonne id�e de faire * CHOOSER BROADCAST.
Ceci permettrait � tout h�te en dehors de votre r�seau d'obtenir des
informations sur les h�tes dans votre r�seau. Vous ne voulez probablement
pas communiquer une telle information. En fait, autoriser un choix pour
tout h�te ext�rieur n'est probablement pas tr�s utile de toute fa�on, car
vous ne devriez pas autoriser des connexions arbitraires directes non plus.
Quand vous avez reconfigur� xdm, envoyez-lui le signal HUP pour
le forcer � relire ses fichiers de configuration.
# kill -HUP pid-of-xdm
#
Techniquement, pour autant que je puisse le voir, XDMCP n'est pas tout �
fait ce � quoi vous pouvez vous attendre d'apr�s la description ci-dessus.
xdm peut rediriger des serveurs X se connectant, vers un autre endroit
et il utilise cette astuce pour impl�menter la liste de choix. Ainsi, le
choix se produit dans xdm et non dans le serveur X bien que la liste de
choix soit repr�sent�e dans l'affichage du serveur X. C'est �galement pour
cela que l'option -once du serveur X ne se combine pas avec
-indirect.
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.
xterm Xt error: Can't open display:
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 -display.
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 setenv ou export selon votre shell).
_X11TransSocketINETConnect: Can't connect: errno = 101
xterm Xt error: Can't open display: love.dial.xs4all.nl:0
Erreur 101 signifie « R�seau inaccessible ». L'application n'arrive pas � se
connecter au serveur � travers le r�seau.
V�rifiez que la variable 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).
_X11TransSocketINETConnect: Can't connect: errno = 111
xterm Xt error: Can't open display: love.dial.xs4all.nl:0
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.
Sinon, il est possible que le serveur X a �t� configur� pour ne pas
�couter sur le port TCP habituel. Pour savoir s'il s'agit de ce cas,
regardez si le serveur X a �t� lanc� avec le param�tre -nolisten tcp
et si oui, enlevez-le.
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
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).