El Lunes 27 Noviembre 2006 22:30, Luciano escribió: > otra vez me paso lo mismo :S > trate de hacer lo del xhost y nada :( >
Usar xhost es por demás de inseguro. Aquí una explicación de Emiliano que vio el post y quiso colaborar: http://pastebin.com/835557 Muchas veces pasa que algunos usuarios preguntan: "Porque no puedo correr (pongan su aplicación X aqui) como root?" El problema viene dado porque X dispone de ciertos mecanismos de seguridad, los cuales impiden que cualquiera pueda conectarse a nuestro display y mostrar ventanas. La página del manual de Xsecurity(7) nos da una lista de los métodos de control de acceso disponibles. El primer método de control esta basado en hosts, y se controla con la utilidad xhost(1). Sin embargo, la página advierte que "Cualquier cliente de un host listado en la lista de control de accesos de hosts tiene permitido acceder al servidor X. Este sistema puede trabajar razonablemente bien en un ambiente donde todos confían en todos" Si además estamos conectados a internet, estamos en un serio problema: no es precisamente un lugar donde "todos confian en todos" Desgraciadamente, la respuesta a la pregunta de arriba casi siempre es "ejecuta xhost +" lo cual es un muy serio error de seguridad. Funciona, si, pero no solo para la persona que quería hacerlo, sino para todos los que puedan querer conectarse. Ahora bien, si pasamos al segundo método de control de accesos, veremos que, si bien no es una maravilla de seguridad, al menos no expone la máquina como la solución del "xhost +". Dicho método (MIT-MAGIC-COOKIE-1) se controla mediante la utilidad xauth(1). Veamos que pasa en mi máquina: $ su - Password: Terminal type is xterm. [EMAIL PROTECTED]:~# kate kate: cannot connect to X server [EMAIL PROTECTED]:~# export DISPLAY=:0 [EMAIL PROTECTED]:~# kate Xlib: connection to ":0.0" refused by server Xlib: No protocol specified kate: cannot connect to X server :0 [EMAIL PROTECTED]:~# El mismo problema que generó la pregunta inicial. Si hiciera xhost + tendría resuelto este problema, pero a costa de generar uno mucho peor. Hagámoslo con xauth. [EMAIL PROTECTED] exit logout $ xauth -n list 192.168.6.3:0 MIT-MAGIC-COOKIE-1 73df0129397a17256f13dcdc55f9f150 pepe.dominio.net/unix:0 MIT-MAGIC-COOKIE-1 73df0129397a17256f13dcdc55f9f150 $ Vemos que tengo la posibilidad de acceder mediante dos métodos: tcp (entrada 192.168.6.3:0, puerto 6000) y sockets unix (pepe.dominio.net/unix:0). Exportemos la MAGIC-COOKIE a un archivo asi podemos importarla en otro lugar (en este caso, el root) $ xauth extract authfile $DISPLAY $ su - Password: Terminal type is xterm. [EMAIL PROTECTED]:~# kate kate: cannot connect to X server [EMAIL PROTECTED]:~# export DISPLAY=:0 [EMAIL PROTECTED]:~# kate Xlib: connection to ":0.0" refused by server Xlib: No protocol specified kate: cannot connect to X server :0 [EMAIL PROTECTED]:~# xauth merge /home/user/authfile [EMAIL PROTECTED]:~# kate & [EMAIL PROTECTED]:~# xauth list maq033.imae.fceia.unr.edu.ar/unix:0 MIT-MAGIC-COOKIE-1 73df0129397a17256f13dcdc55f9f150 Finalmente anduvo, y sin necesidad de abrir mi display al mundo. Puedo conectarme a la X sin problemas. Este archivo podría copiarlo a otras máquinas de mi red interna, importarlo con xauth y conectarme desde ahi. Finalmente, unas aclaraciones y/o recomendaciones: * El método no es una panacea de seguridad, ya que la cookie se transmite en texto plano en las conexiones de red. * Si realmente somos paranoicos (al menos yo lo soy) deberemos directamente deshabilitar la conexión a la X mediante tcp (la opcion es -nolisten tcp en el comando que lanza la X), aunque esto nos impide conectarnos desde otra máquina. * Si lo hacemos todo localmente, podríamos directamente, como root, haber apuntado la "base de datos" de cookies a la del usuario en cuestión: [EMAIL PROTECTED]:~# XAUTHORITY=/home/usuario/.Xauthority kate & y también andaría (aunque es un método un tanto rudo para el usuario, sobre todo si no es el mismo que el root !!!). Para mi gusto este sería el consejo rápido y sucio para darle a alguien en vez del "xhost +". * Si no andamos muy peleados con el inglés, leer las páginas de manual de X(7), xdm(1), Xsecurity(7), Xserver(1), xhost(1) y xauth(1). Y si, ya se que son muchas, pero como dice un viejo preoverbio chino "Sigue el sagrado camino del RTFM, pequeño saltamontes ..." * En http://tldp.org/HOWTO/Remote-X-Apps.html esta el howto que me hizo ver el tema este del xhost vs xauth. * Leer el código fuente de startx(1) es instructivo al respecto , sobre todo la parte final. * La última: en algunos sistemas (p.ej *BSD), el resolver de hosts es muy puntilloso en cuanto a los nombres de archivo y como se resuelven a IPs. Si algunos andan con problemas de delays para que se le lancen las aplicaciones X, puede ser que haya un problema de este tipo y hay que esperar el timeout de la consulta para ir a la IP directamente. Asegurense que su nombre de host siempre se resuelva bien, sea mediante /etc/hosts o DNS. Espero que ayude. -- Sebastián D. Criado - scriado{en}ciudad.com.ar L.U.G.R.o - http://www.lugro.org.ar GNU/Linux Registered User # 146768 ------------------------------------------------------------------- "Si el Universo fuera un programa estaría hecho en C, y correría sobre un sistema UNIX" Anónimo.
pgpNfr6uBvQnW.pgp
Description: PGP signature
