He iniciado sesión de forma remota a través de SSH con X reenviando a una máquina que ejecuta Ubuntu 10.04 (lúcido). La mayoría de las aplicaciones X11 (por ejemplo, xterm, gnome-terminal) funcionan bien. Pero Evince no arranca. Parece incapaz de leer ~/.Xauthority, aunque el archivo existe y evidentemente es legible (tiene los permisos correctos y otras aplicaciones lo leen bien).
$ evince
X11 connection rejected because of wrong authentication.
Cannot parse arguments: Cannot open display:
$ echo DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY
DISPLAY=localhost:10.0 XAUTHORITY=
$ strace evince
…
access("/home/gilles/.Xauthority", R_OK) = 0
open("/home/gilles/.Xauthority", O_RDONLY) = -1 EACCES (Permission denied)
…
$ ls -l ~/.Xauthority
-rw------- 1 gilles gilles 496 Jul 5 13:34 /home/gilles/.Xauthority
¿Qué tiene de especial Evince que no puede leer ~/.Xauthority? ¿Cómo puedo hacer que empiece?
Respuesta1
TL,DR: es culpa de Apparmor y debido a que mi directorio personal está fuera de /home.
En una instalación predeterminada de Ubuntu 10.04, elaparienciaEl paquete se incorpora como una dependencia indirecta a nivel de Recomendaciones delestándar de ubuntupaquete. Los registros del sistema ( /var/log/syslog) muestran que Apparmor rechaza el intento de Evince de leer ~/.Xauthority:
Jul 5 17:58:31 darkstar kernel: [15994724.481599] type=1503 audit(13415 03911.542:168): operation="open" pid=9806 parent=9805 profile="/usr/bin/evince" requested_mask="r::" denied_mask="r::" fsuid=1001 ouid=1001 name="/elsewhere/home/gilles/.Xauthority"
La configuración predeterminada de Evince para Apparmor (en /etc/apparmor.d/usr.bin.evince) es muy permisiva: permite lecturas y escrituras arbitrarias en todos los directorios de inicio. Sin embargo, mi directorio de inicio en esta máquina es un enlace simbólico a una ubicación no estándar que no figura en la configuración predeterminada de AppArmor. El acceso está permitido en /home, pero la ubicación real de mi directorio personal es /elsewhere/home/gilles, por lo que el acceso está denegado.
Otras aplicaciones que podrían verse afectadas por este problema incluyen:
- Firefox, pero su perfil esdeshabilitado por defecto(por la presencia de un enlace simbólico
/etc/apparmor.d/disable/usr.bin.firefox -> /etc/apparmor.d/usr.bin.firefox). - TAZAS Impresión de PDF; No lo he probado, pero espero que no se pueda escribir en
~/PDF.
Mi solución fue editar /etc/apparmor.d/tunables/home.d/localy agregar la línea.
@{HOMEDIRS}+=/elsewhere/home/
para que se reconozca la ubicación no estándar de los directorios de inicio (tenga en cuenta que la final /es importante; consulte los comentarios en /etc/apparmor.d/tunables/home.d/ubuntu), luego ejecute /etc/init.d/apparmor reloadpara actualizar la configuración de Apparmor.
Si no tiene privilegios de administrador y el administrador del sistema no responde, puede copiar el evincebinario a una ubicación diferente, como por ejemplo ~/bin, y no estará cubierto por la política de Apparmor (por lo que podrá iniciarlo, pero no se le brindará la muy limitada seguridad adicional que proporciona Apparmor).
Este problema ha sido reportado comoError de Ubuntu #447292. La resolución maneja el caso en el que algunos usuarios tienen su directorio de inicio listado en /etc/passwdoutside /home, pero no casos como el mío, donde /home/gilleshay un enlace simbólico.
Respuesta2
Tuve el mismo problema y tu respuesta me indicó la dirección correcta. Encontré una solución diferente que no requiere editar la configuración de la aplicación. En lugar de utilizar un enlace simbólico para redirigir el acceso /home, utilice la bindopción en mount. Agregué la siguiente línea a /etc/fstab:
/elsewhere/home /home none bind
Una vez que haga esto, Apparmor ni siquiera sabrá que los directorios que aparecen a continuación /homeestán "realmente" ubicados en otro lugar, por lo que las quejas desaparecerán.
La ventaja de este enfoque es que funcionará para todas las aplicaciones, sin tener que editar un archivo de configuración de apparmor diferente para cada una.