Evince kann nicht gestartet werden, da .Xauthority nicht gelesen werden kann

Ich bin remote über SSH mit X-Weiterleitung an einen Computer angemeldet, auf dem Ubuntu 10.04 (lucid) ausgeführt wird. Die meisten X11-Anwendungen (z. B. xterm, gnome-terminal) funktionieren einwandfrei. Aber Evince fängt nicht an. Es scheint nicht lesbar zu sein ~/.Xauthority, obwohl die Datei vorhanden ist, und ist offensichtlich lesbar (es hat die richtigen Berechtigungen und andere Anwendungen lesen sie einwandfrei).

$ 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

Was ist so besonders an Evince, dass es nicht lesen kann ~/.Xauthority? Wie kann ich es starten lassen?

TL, DR: Es ist Apparmors Schuld und weil mein Home-Verzeichnis außerhalb ist /home.

Bei einer Standardinstallation von Ubuntu 10.04 wird das Apparmor- Paket als indirekte Abhängigkeit des Ubuntu-Standardpakets auf Empfehlungsebene abgerufen . Die Systemprotokolle ( /var/log/syslog) zeigen, dass Apparmor Evince 'Leseversuch ablehnt ~/.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"

Die Standardkonfiguration von Evince für Apparmor (in /etc/apparmor.d/usr.bin.evince) ist sehr zulässig: Sie ermöglicht beliebige Lese- und Schreibvorgänge in allen Home-Verzeichnissen. Mein Ausgangsverzeichnis auf diesem Computer ist jedoch eine symbolische Verknüpfung zu einem nicht standardmäßigen Speicherort, der in der Standardkonfiguration von AppArmor nicht aufgeführt ist. Der Zugriff ist unter zulässig /home, aber der tatsächliche Speicherort meines Home-Verzeichnisses ist /elsewhere/home/gilles, sodass der Zugriff verweigert wird.

Andere Anwendungen, die von diesem Problem betroffen sein könnten, sind:

• Firefox, aber sein Profil ist standardmäßig deaktiviert (durch das Vorhandensein eines symbolischen Links /etc/apparmor.d/disable/usr.bin.firefox -> /etc/apparmor.d/usr.bin.firefox).
• CUPS PDF-Druck; Ich habe nicht getestet, aber ich erwarte, dass das Schreiben fehlschlägt ~/PDF.

Mein Fix war, /etc/apparmor.d/tunables/home.d/localdie Zeile zu bearbeiten und hinzuzufügen

@{HOMEDIRS}+=/elsewhere/home/

Um den nicht standardmäßigen Speicherort der Basisverzeichnisse zu erkennen (beachten Sie, dass das Finale /wichtig ist; siehe Kommentare in /etc/apparmor.d/tunables/home.d/ubuntu), führen Sie es aus /etc/init.d/apparmor reload, um die Apparmor-Einstellungen zu aktualisieren.

Wenn Sie keine Administratorrechte haben und der Systemadministrator nicht reagiert, können Sie die evinceBinärdatei an einen anderen Speicherort kopieren, z. B. ~/bin, und sie wird von der Apparmor-Richtlinie nicht abgedeckt (Sie können sie jedoch starten, aber wird nicht die sehr begrenzte zusätzliche Sicherheit erhalten, die Apparmor bietet).

Dieses Problem wurde als Ubuntu-Fehler # 447292 gemeldet . Die Auflösung behandelt den Fall, dass einige Benutzer ihr Ausgangsverzeichnis wie /etc/passwdaußen aufgeführt haben /home, nicht jedoch Fälle wie meines, in denen /home/gillesein symbolischer Link vorhanden ist.

Hatte das gleiche Problem und Ihre Antwort zeigte mir die richtige Richtung. Ich habe eine andere Lösung gefunden, bei der die Apparmor-Konfiguration nicht bearbeitet werden muss. /homeVerwenden Sie die bindOption ein, anstatt einen Symlink zum Umleiten des Zugriffs zu verwenden mount. Ich habe die folgende Zeile hinzugefügt /etc/fstab:

/elsewhere/home /home none bind

Sobald Sie dies tun, wird Apparmor nicht einmal wissen, dass sich die Verzeichnisse unter /home"wirklich" woanders befinden, sodass die Beschwerden verschwinden .

Der Vorteil dieses Ansatzes besteht darin, dass er für alle Anwendungen funktioniert, ohne dass für jede Anwendung eine andere Apparmor-Konfigurationsdatei bearbeitet werden muss.