¿Dejar que Xorg escuche en TCP, pero solo a localhost?

Tengo algún programa de cliente X que necesita acceso a un servidor X. Solo puede acceder al servidor X por TCP, no por otros métodos como los sockets de dominio Unix. Se ejecutará en el mismo host que el servidor, para facilitar las cosas.

Entonces, ¿cómo puedo hacer que mi servidor Xorg escuche en el puerto TCP 6000, pero solo para conexiones desde localhost?

Encontré ¿Cómo hacer que X.org escuche conexiones remotas en el puerto 6000? , que explica cómo habilitar el acceso para hosts remotos, pero realmente no quiero acceso remoto (por razones de seguridad, principalmente).

Pensé en reenviar de alguna manera el transporte predeterminado a TCP, pero realmente no encontré información sobre cuál es el transporte predeterminado.

(Estoy usando kdm como mi administrador de pantalla aquí, pero creo que puedo transferir soluciones para el administrador de pantalla, o incluso cambiar el administrador de pantalla).

¿Algunas ideas?

Esto está en 11.04 en una instalación mixta Kubuntu-Ubuntu-XUbuntu (originalmente Kubuntu, pero agregué ubuntu-desktop y xubuntu-desktop. En el arranque ahora dice Xubuntu 11.04). Ahora estoy usando el escritorio gnome-classic, creo, de KDM.

11.04 xorg localhost

— Paŭlo Ebermann
fuente

Para todos los que se preguntan qué es este cliente X: De hecho, es una implementación Java SSH ( JSch ) que intenta hacer el reenvío X a otro host. Java realmente no puede acceder a los sockets de dominio Unix, creo. El mismo problema también se aplicaría a otro proyecto mío (ahora en pausa), donde quería implementar un cliente X en Java puro (por ejemplo, leyendo / escribiendo un socket, sin usar alguna biblioteca de ventanas).

— Paŭlo Ebermann

@Paulo, java en realidad puede usar sockets de dominio de Unix (puede escribir una biblioteca nativa que proporcionará acceso a las llamadas al sistema necesarias, o simplemente encontrarlas ya escritas). Pero luego, ahora, efectivamente pierde el principal beneficio de Java: alta portabilidad. Entonces, si lo necesitara realmente, podría escribir fácilmente la biblioteca de cliente X en Java que funcionaría sobre PF_LOCAL. Tenga en cuenta también que la interfaz TCP sobre loopback tiene una sobrecarga mucho mayor que el socket estándar de Unix.

— ulidtko

Sí, encontré algunas bibliotecas, pero esto no me ayudará mientras no conozca la dirección UDS real. ¿Está esto documentado en alguna parte?

— Paŭlo Ebermann

@Paulo, los sockets de dominio de Unix suelen usar el espacio de nombres del sistema de archivos. Sus direcciones son nombres de archivo . Los nodos de archivo respectivos son "archivos de socket especiales". En mi sistema tengo numerosas conexiones /tmp/.X11-unix/X0: este es un ejemplo de dirección AF_UNIX (se usa netstat -xpara ver la suya). La especificación del protocolo X11 debe determinar las direcciones exactas para conectarse. Y realmente DEBE leerlo si está escribiendo una biblioteca cliente para ese protocolo.

— ulidtko

/tmp/.X11-unix/X0existe como un socket aquí (OpenSUSE), también, lo comprobaré nuevamente en casa (en el sistema Ubuntu nombrado en la pregunta). Ahora solo tengo que ver cómo reenviar esto a un socket TCP a 6000.

— Paŭlo Ebermann

Respuestas:

Parece que una solución sería el uso de socat. Aquí hay una línea de comando que parece funcionar, si el servidor X aún no se ejecuta en TCP:

socat -d -d TCP-LISTEN:6000,fork,bind=localhost UNIX-CONNECT:/tmp/.X11-unix/X0

Entonces puedo hacer

xlogo -display localhost:0

Curiosamente, no parece funcionar si lo dejo escuchar en 6001 y luego especifico la pantalla en localhost:1lugar de localhost:0- obtengo No protocol specified. Parece que tendré que leer el protocolo X nuevamente. (Y sobre JSch se cierra Invalid MIT-MAGIC-COOKIE-1 key, pero este es otro problema).

— Paŭlo Ebermann
fuente

¡¡Si!! Había estado buscando una manera de hacer xserver-allow-tcp=true después de X ya se había iniciado con la -nolisten tcp de /etc/X11/xinit/xserverrcsin necesidad de reiniciar. Solo en mi caso, bind=0.0.0.0para permitir mis hosts externos.

— Marcos

El código Xorg actualmente no tiene ninguna opción para controlar qué interfaces escuchar. No debería ser difícil de agregar, pero debería ser aún más fácil simplemente configurar su firewall para bloquear las conexiones entrantes al puerto 6000 desde otras máquinas.

— alanc
fuente

Solo algunos otros pensamientos ...

Permitir pero bloquear con xhost (y / o filtrado de red)

La forma tradicional de hacer esto es que el servidor X escuche en el socket TCP y use xhost para determinar qué hosts pueden conectarse. Consulte la página del manual para xhost (1). (Además, por supuesto, la dirección IP y el filtrado de puertos también ayudarían aquí, como lo han señalado las sugerencias anteriores).

Solo escuche en la interfaz local

Según el comentario de alanc anterior, no hay código allí ahora, ¡pero casi!

Recuerde que (casi) todos los hosts tienen al menos dos interfaces, la interfaz loopback lo0 (siempre 127.0.0.1) y la ethernet eth0 normal (o wlan0 o lo que sea, que digamos es 192.168.0.128) y muchas tienen más. Por lo general, los servidores TCP / IP (es decir, el servidor X) permitirán conexiones entrantes a cualquiera de sus direcciones IP en cualquiera de sus interfaces, pero la mayoría del software le permitirá especificar una dirección IP si lo desea. El trabajo real se realiza mediante bind (2), que toma INADDR_ANY (0.0.0.0) o una dirección IP real.

El servidor Xorg implementa -name local-address pero desafortunadamente esto es solo para XDMCP (vea el archivo os / xdmcp.c que lo implementa correctamente hasta donde yo sé). La conexión real para el protocolo X, creo, es realizada por SocketINETCreateListener en el archivo /usr/include/X11/Xtrans/Xtranssock.c, que establece la dirección en INADDR_ANY y luego se enlaza a ella sin más procesamiento. Lo que se necesitaría es el indicador -from (que es tratado por os / xdmcp.c como FromAddress) para conectarse de alguna manera a la variable 'sockname' justo antes de SocketCreateListener () en Xtranssock.c. El problema, por supuesto, es que todas las cosas de transporte se hacen realmente de una manera neutral en el transporte, por lo que es un poco complicado ingresar la información en Xtranssock.c.

Las rutas de los archivos, etc., pueden variar, se observó con Ubuntu 10.04 LTS y se observó que los nombres de las funciones en Xtranssock.c cambiaron por una macro TRANS. http://cgit.freedesktop.org/xorg/xserver/tree/os/xdmcp.c

Espero que sea de alguna utilidad.

Saludos cordiales

Jonathan

— Jonathan
fuente

Por ahora, estoy usando la autenticación de cookies mágicas, por lo que ni siquiera se permitirán conexiones desde el mismo host. xhostampliaría el acceso, no lo reduciría.

— Paŭlo Ebermann

Y no creo que piratee mi servidor X, pero gracias por la sugerencia sobre dónde hacerlo.

— Paŭlo Ebermann

9 años después y esto no ha cambiado. gitlab.freedesktop.org/xorg/lib/libxtrans/blob/master/…

— daveloyall el