Laisser Xorg écouter sur TCP, mais uniquement sur localhost?
J'ai un programme client X qui nécessite un accès à un serveur X. Il est seulement capable d'accéder au serveur X par TCP, pas par d'autres méthodes comme les sockets de domaine unix. Il fonctionnera sur le même hôte que le serveur, pour faciliter les choses.
Alors, comment puis-je faire en sorte que mon serveur Xorg écoute sur TCP port 6000, mais uniquement pour les connexions à partir de localhost?
J'ai trouvé Comment faire en sorte que X.org écoute les connexions distantes sur le port 6000? , ce qui explique comment activer l'accès pour les hôtes distants, mais je ne veux pas vraiment d'accès distant (pour des raisons de sécurité, principalement) .
J'ai envisagé de transférer le transport par défaut vers TCP, mais je n'ai pas vraiment trouvé d'informations sur le transport par défaut.
(J'utilise kdm en tant que gestionnaire d'affichage ici, mais je pense que je peux transférer des solutions pour l'un ou l'autre, voire changer de gestionnaire.)
Des idées?
C'est le 11.04 sur une installation mixte de Kubuntu-Ubuntu-XUbuntu (à l'origine Kubuntu, mais j'ai ajouté ubuntu-desktop et xubuntu-desktop. Au démarrage, Xubuntu 11.04 est maintenant affiché. J'utilise maintenant le bureau gnome-classic, je pense, de KDM.
Une solution de contournement consisterait en l'utilisation de socat . Voici une ligne de commande qui semble fonctionner, si le serveur X ne s’exécute pas déjà sur TCP:
socat -d -d TCP-LISTEN:6000,fork,bind=localhost UNIX-CONNECT:/tmp/.X11-unix/X0
Alors je peux faire
xlogo -display localhost:0
Bizarrement, cela ne semble pas fonctionner si je le laisse écouter sur 6001 puis spécifie l’affichage localhost:1 au lieu de localhost:0 - j’obtiens No protocol specified. Il semble que je devrai relire le protocole X. (Et sur JSch, il se ferme alors avec Invalid MIT-MAGIC-COOKIE-1 key, mais c'est un autre problème.)
Le code Xorg n'a actuellement aucune option pour contrôler les interfaces sur lesquelles écouter. Cela ne devrait pas être difficile à ajouter, mais il devrait être encore plus facile de configurer simplement votre pare-feu pour bloquer les connexions entrantes sur le port 6000 depuis d'autres ordinateurs.
Juste quelques autres pensées ...
- Autoriser mais bloquer avec xhost (et/ou filtrage réseau)
La méthode traditionnelle consiste à ce que le serveur X écoute le socket TCP et utilise xhost pour déterminer les hôtes autorisés à se connecter. Voir la page de manuel pour xhost (1). (En outre, bien entendu, le filtrage des adresses IP et des ports aiderait ici aussi, comme indiqué dans les suggestions précédentes.)
- Ecoute uniquement sur l'interface locale
Par commentaire d'Alanc ci-dessus, il n'y a pas de code là maintenant, mais presque!
N'oubliez pas que (presque) tous les hôtes ont au moins deux interfaces, l'interface de bouclage lo0 (toujours 127.0.0.1) et l'éthernet normal eth0 (ou wlan0 ou autre, soit 192.168.0.128) et beaucoup plus. Habituellement, les serveurs TCP/IP (serveur X) autorisent les connexions entrantes vers l’une de leurs adresses IP sur l’une de leurs interfaces, mais la plupart des logiciels vous permettent de spécifier une adresse IP si vous le souhaitez. Le travail réel est effectué par bind (2), qui prend soit INADDR_ANY (0.0.0.0), soit une adresse IP réelle.
Le serveur Xorg implémente -name local-address mais malheureusement, il s’agit uniquement de XDMCP (voir le fichier os/xdmcp.c qui l’implémente correctement pour autant que je sache.) La connexion réelle pour le protocole X, je crois, est effectuée par SocketINETCreateListener dans le fichier /usr/include/X11/Xtrans/Xtranssock.c, qui définit l'adresse sur INADDR_ANY, puis la lie sans traitement supplémentaire. Ce qui serait nécessaire, c'est l'indicateur -from (qui est traité par os/xdmcp.c en tant que FromAddress) pour se connecter en quelque sorte à la variable 'sockname' juste avant SocketCreateListener () dans Xtranssock.c. Le problème, bien sûr, est que toutes les opérations de transport sont réellement effectuées de manière neutre, il est donc un peu délicat d’obtenir les informations dans Xtranssock.c.
Les chemins de fichiers, etc. peuvent varier, ont été examinés avec Ubuntu 10.04 LTS et notez que les noms de fonction dans Xtranssock.c ont été modifiés par une macro TRANS. http://cgit.freedesktop.org/xorg/xserver/tree/os/xdmcp.c
J'espère que c'est utile.
Sincères amitiés
Jonathan.