Cómo usar xauth para ejecutar aplicaciones gráficas a través de otro usuario en Linux

48

Mi cuenta de usuario habitual es, digamos, usuario1. Creé user2 por separado para alguna aplicación x que me gustaría ejecutar mientras estoy conectado a x como user1 pero de una manera que evitará que tenga acceso de lectura / escritura a los datos de user1. Pensé que podría usar xauth y sudo / su para user2 desde user1 para ejecutar esta aplicación. ¿Cómo hago esto? No estoy seguro de cómo configurar xauth.

linux sudo

— Phil
fuente

32

Para usar xauth selectivamente, como usuario1 ejecuta:

xauth list|grep `uname -n`

Esto imprime las entradas de autorización hexkey por usted. También podría tener diferentes pantallas asociadas con esos hosts.

Como usuario2 configure su pantalla (suponiendo un caso predeterminado):

DISPLAY=:0; export DISPLAY

Entonces corre:

xauth add $DISPLAY . hexkey

Tenga en cuenta el punto después de $ DISPLAY y antes de la tecla hexagonal.

Cuando ya no se necesita acceso, como usuario2 puede ejecutar:

xauth remove $DISPLAY

— Randall
fuente

Problema 1: user2 no tiene ningún .Xauthorityarchivo en el directorio de inicio de user2. Problema 2: de alguna manera y por alguna razón no entiendo, después su, XAUTHORITY mantiene la ruta del archivo a user1's. Pero ese archivo no es legible por el usuario2.

— Oteo

Parece que olvidaste unset XAUTHORITY bajo

— user2

¿Es hexkeyen el xauth addcomando el mismo que desde xauth listo tengo que crear uno nuevo al azar?

— bonanza

bonanza: es el único resultado de la lista xauth.

— John Eikenberry

1

Otra forma de hacerlo es algo así como ... "xauth extract - $ DISPLAY | sudo -iu steam xauth merge -". En este caso, tengo XAUTHORITY establecido en .profile, por lo que el 'sudo -i' tiene ese conjunto correcto.

— John Eikenberry

12

Puse mi .zshrclínea con export XAUTHORITY=~/.Xauthorityy ahora soy capaz de ejecutar sudo -E xcommand. Después de mucho googlear, esta fue la forma más fácil para mí.

— kfl62
fuente

1

Tenga en cuenta que este procedimiento normalmente no requeriría su uso sudo -E(y el uso -Eestá deshabilitado en la mayoría de las instalaciones predeterminadas) porque normalmente la sudoersconfiguración predeterminada permitiría XAUTHORITYpasar la variable de entorno a sudo.

— Guss

@Guss No requiere -E . Se puede establecer como una variable que se puede pasar, y Red Hat o Debian lo sugieren.

— Daniel C. Sobral

@ DanielC.Sobral - eso es lo que dije :-)

— Guss

@ Guss Oh, lo siento. Invertí de alguna manera cada oración que escribiste. :-)

— Daniel C. Sobral

Todavía no funcionó para mí, en Mac OS X con zsh

— Sridhar Sarnobat

9

Asumiendo debian o ubuntu (debería ser similar en Red Hat / SUSE).

sudo apt-get install sux
sux user -c 'command'

— ehempel
fuente

+1 buena respuesta, no tiene sentido reinventar la rueda. Por cierto, sux hace principalmente lo que sugiere mi respuesta anterior. Es más potente y fácil de usar, por supuesto.

— sleske

Puede notar que 'sux' es un simple script de shell, también ...

— Martin Mächler

55

suxno se mantiene (y se elimina de los repositorios de Debian / Ubuntu): packages.qa.debian.org/s/sux/news/20140101T172633Z.html

— Rob W

9

Primero: no lo use xhost +, es bastante inseguro (permitir / rechazar).

Más bien use el mecanismo X-Cookie:

su user2
cp /home/user1/.Xauthority /home/user2/.Xauthority 
export DISPLAY=:0

Alternativamente, si lo ha suxinstalado, úselo (vea la respuesta de ehempel).

En ambos casos, user2 usará la cookie secreta en .Xauthority para autorizar al servidor X, y nadie más tendrá acceso a ella.

Notas:

Dependiendo de sus permisos de archivo, es posible que deba copiar .Xauthority de alguna otra manera.
En lugar de copiar .Xauthority, también puede usar xauthpara extraer y copiar la clave de autorización (consulte la respuesta de Randall). Si tiene varias claves en el .Xauthorityarchivo, esto es más selectivo; de lo contrario es cuestión de gustos.

— sleske
fuente

Sí, tengo acceso de root en esa máquina

— Phil

Esto es simplemente copiar manualmente las cookies de xauth a través del acceso raíz. Esto no es diferente de usar xauth como Randall explica en la respuesta principal (actual), excepto que copia cada cookie que mostraría 'xauth list'. Por lo tanto, esto es menos seguro que la respuesta xauth superior que solo agregaría las cookies que elija.

— John Eikenberry

@JohnEikenberry: Cierto, gracias por señalar esto. Actualicé mi respuesta.

— sleske

7

Esto solucionará el problema para todos los usuarios:

cat <<EOF > /etc/profile.d/xauth.sh
#!/sbin/bash
export XAUTHORITY=~/.Xauthority
EOF

— JMS
fuente

Esto es básicamente lo que he hecho y funciona muy bien, ¡gracias!

— Guss

4

Como root:

xhost local:yourusername

Donde su nombre de usuario es su nombre de usuario :)

Luego haga su como su usuario xclockdebería funcionar si está instalado

— ACV
fuente

2

Estos son solo hacks:

xauth + (inseguro)
ssh -X user2 @ localhost (feo)

sleske anterior tiene, creo, la solución adecuada.

— alex
fuente

ssh -Xes una solución muy simple y elegante, que no depende de ningún material gtk / kde desaprobado / no mantenido (que requiere instalar más binarios con bit SUID ...).

— Stefan

2

Encontré algo que me funciona muy bien en KDE

kdesu -u username /path/to/program

— Phil
fuente

En la parte debian de kde-cli-tools, y no en $PATHsino en /usr/lib/x86_64-linux-gnu/libexec/kf5/kdesu(obviamente, dependiendo de la arquitectura).

— Stefan

0

De esta manera hecho en suse / opensuse: http://www.novell.com/support/kb/doc.php?id=7003743

Simplemente modificando /etc/pam.d/su, agregando la opción (negrita):

sesión opcional pam_xauth.so systemuser = 1

Entonces puede cambiar con su sin -:

su user2

y ejecuta la aplicación gráficamente.

— pojem
fuente

-1

Para GNOME (y sin ningún entorno de escritorio realmente, lo uso solo con icewm) gksu:

gksu -u username program

— Matija Nalis
fuente

"gksu ha quedado en desuso durante años": bugs.debian.org/cgi-bin/bugreport.cgi?bug=867236

— Stefan

@Stefan nota que este error de Debian se trata de la premisa de que elevar los privilegios para todo el programa es una mala idea, y que el programa debería modificarse para ejecutar solo ayudantes mínimos con privilegios elevados (usando PolicyKit). Esta pregunta (y mi respuesta) se trata de reducir los privilegios, que es otra cosa completamente diferente y, de hecho, es una buena idea (por ejemplo, para la navegación aleatoria tengo un acceso directo que ejecuta Firefox en una cuenta menos privilegiada que mi cuenta predeterminada, por lo que cualquier exploit allí puede toca mis datos - y gksu (8) está bastante bien para eso)

— Matija Nalis

Todo eso está bien, pero usar un binario SUID en desuso y sin mantenimiento es simplemente incorrecto. Esta respuesta podría haber sido útil en el pasado, pero ya no lo es.

— Stefan