Evince ne parvient pas à démarrer car il ne peut pas lire .Xauthority

Je suis connecté à distance via SSH avec le transfert X vers une machine exécutant Ubuntu 10.04 (lucide). La plupart des applications X11 (par exemple xterm, gnome-terminal) fonctionnent correctement. Mais Evince ne démarre pas. Il semble incapable de lire ~/.Xauthority, même si le fichier existe, et est évidemment lisible (il a les bonnes autorisations et d'autres applications le lisent très 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

Quelle est la particularité d'Evince qu'il ne sait pas lire ~/.Xauthority? Comment puis-je le faire démarrer?

TL, DR: c'est la faute d'Apparmor, et parce que mon répertoire personnel est à l'extérieur /home.

Sous une installation par défaut d'Ubuntu 10.04, le package apparmor est récupéré en tant que dépendance indirecte au niveau Recommends du package ubuntu standard . Les journaux système ( /var/log/syslog) montrent que Apparmor rejette la tentative d'Evince de lire ~/.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 configuration Evince par défaut pour Apparmor (in /etc/apparmor.d/usr.bin.evince) est très permissive: elle permet des lectures et des écritures arbitraires dans tous les répertoires personnels. Cependant, mon répertoire personnel sur cette machine est un lien symbolique vers un emplacement non standard qui n'est pas répertorié dans la configuration AppArmor par défaut. L'accès est autorisé sous /home, mais l'emplacement réel de mon répertoire personnel est /elsewhere/home/gilles, donc l'accès est refusé.

Les autres applications susceptibles d'être affectées par ce problème sont les suivantes:

• Firefox, mais son profil est désactivé par défaut (par la présence d'un lien symbolique /etc/apparmor.d/disable/usr.bin.firefox -> /etc/apparmor.d/usr.bin.firefox).
• Impression PDF CUPS; Je n'ai pas testé, mais je m'attends à ce qu'il échoue à écrire ~/PDF.

Mon correctif était de modifier /etc/apparmor.d/tunables/home.d/localet d'ajouter la ligne

@{HOMEDIRS}+=/elsewhere/home/

pour que l'emplacement non standard des répertoires personnels soit reconnu (notez que la finale /est importante; voir les commentaires dans /etc/apparmor.d/tunables/home.d/ubuntu), puis exécutez /etc/init.d/apparmor reloadpour mettre à jour les paramètres de l'Apparmor.

Si vous ne disposez pas de privilèges d'administrateur et que l'administrateur système ne répond pas, vous pouvez copier le evincebinaire vers un emplacement différent tel que ~/bin, et il ne sera pas couvert par la stratégie de l'Apparmeur (vous pourrez donc le démarrer, mais ne bénéficiera pas de la sécurité supplémentaire très limitée fournie par Apparmor).

Ce problème a été signalé comme bogue Ubuntu # 447292 . La résolution gère le cas où certains utilisateurs ont leur répertoire personnel comme indiqué à l' /etc/passwdextérieur /home, mais pas les cas tels que le mien où /home/gillesest un lien symbolique.

J'ai eu le même problème, et votre réponse m'a orienté dans la bonne direction. J'ai trouvé une solution différente qui ne nécessite pas de modifier la configuration de l'apparmeur. Au lieu d'utiliser un lien symbolique pour rediriger l'accès à /home, utilisez l' bindoption on mount. J'ai ajouté la ligne suivante à /etc/fstab:

/elsewhere/home /home none bind

Une fois que vous faites cela, l'apparmeur ne saura même pas que les répertoires sous /homesont "vraiment" situés ailleurs, donc les plaintes disparaîtront.

L'avantage de cette approche est qu'elle fonctionnera pour toutes les applications, sans avoir à modifier un fichier de configuration d'apparmeur différent pour chacune.