(Courriels de diversion: <collets@medailles-sous-marinier.com> <rongeant@dorlotes-propagent.com> <noueras@elevons-assembla.com> <econduise@confondrai-devêtiraient.com> <seches@galaxie-pouliner.com> <raboterais@roulotte-dissonante.com> <arrerageant@croupissiez-adultes.com> <non-combattants@benissant-compatissantes.com> <absolue@diluaient-suffisant.com> <mobile@designes-secoua.com> )
>>>>> "be" == Bernard ETIENNE <etienne.b@c-et-f.com> writes:>>>>> "nj" == Nicolas JULIEN <Nicolas.julien@synelec.fr> writes:
be> Xlib: connection to "etienne:0.0" refused by server
be> Xlib: Client is not authorized to connect to Server
be> Application initialization failed: couldn't connect to display "etienne"
nj> il faut taper:
nj> xhost + <le_nom_du_serveur_de_BDD>
// snip depuis les archives, au fait les gars y'a pas mal de choses
// intéressantes dans les archives, qui sont accessibles depuis le
// site web de l'association, cf URL en bas de chaque message
Il y a beaucoup mieux que xhost, qui au pire ("xhost +") élimine toute
protection de votre display, et au mieux permet seulement d'autoriser
l'accès machine par machine. Certes, sur une machine isolée les
risques de sécurité sont réduits, mais j'imagine que tout linuxien
aura un jour à utiliser des machines multiutilisateur en réseau.
Contrôler son display c'est important: une personne qui réussit à y
accéder peut capturer toutes les séquences de touches frappées (penser
mots de passse), et même fabriquer des évènements X bidons qui seront
interprétés par les clients X.
Il vaut mieux utiliser xauth, qui permet d'accorder des droits X par
utilisateur. Lors du lancement de X, une clé de session sera générée,
et stockée dans ~/.Xauthority. Tous les clients X, avant de de pouvoir
se connecter au serveur X, devront connaitre cette clé. Celà se fait
de manière automatique pour les clients lancés sous ton uid, mais
lorsque tu fais un su il faut faire
export XAUTHORITY=/home/user/.Xauthority
ou
xauth merge /home/user/.Xauthority
C'est mieux expliqué (surtout pour le problème plus difficile de
l'execution d'une application sur une machine distante avec affichage
sur le display local) dans http://www.xs4all.nl/~zweije/xauth.html
Encore plus mieux, utiliser ssh avec le forwarding de ports, qui gère
tout ça de manière transparente. Par exemple
% ssh -f -X host /usr/X11R6/bin/xterm
puis tous les clients X11 lancés depuis ce xterm s'adresseront au
display host:10, qui est forwardé par ssh via un tunnel chiffré à
localhost:0, le serveur X11 local donc. [La nécessité du -X dans la
ligne de commande ssh dépend de la version de ssh, cf la page man.]
--
Eric Marsden <URL:http://www.laas.fr/~emarsden/>
---------------------------------------------------------------------
Aide sur la liste: <URL:mailto:linux-31-help@CULTe.org>Le CULTe sur le web: <URL:http://www.CULTe.org/>