☰

Evince kann nicht gestartet werden, da es .Xauthority nicht lesen kann.

tag-icon • tag-icon ubuntu permissions evince apparmor xauth
Evince kann nicht gestartet werden, da es .Xauthority nicht lesen kann.

Ich bin remote über SSH mit X-Weiterleitung auf einem Rechner angemeldet, auf dem Ubuntu 10.04 (Lucid) läuft. Die meisten X11-Anwendungen (z. B. xterm, gnome-terminal) funktionieren einwandfrei. Aber Evince startet nicht. Es scheint nicht lesen zu können ~/.Xauthority, obwohl die Datei existiert und offensichtlich lesbar ist (sie hat die richtigen Berechtigungen und andere Anwendungen lesen sie problemlos).

$ 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 an Evince so besonders, dass es nicht lesen kann ~/.Xauthority? Wie kann ich es starten?

Antwort1

TL,DR: Es ist die Schuld von Apparmor und liegt daran, dass mein Home-Verzeichnis außerhalb liegt /home.

Bei einer Standardinstallation von Ubuntu 10.04 ist dierüstungPaket wird als indirekte Abhängigkeit auf Empfehlungsebene desUbuntu-StandardPaket. Die Systemprotokolle ( /var/log/syslog) zeigen, dass Apparmor den Leseversuch von Evince 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 standardmäßige Evince-Konfiguration für Apparmor (in /etc/apparmor.d/usr.bin.evince) ist sehr freizügig: Sie erlaubt beliebige Lese- und Schreibvorgänge in allen Home-Verzeichnissen. Mein Home-Verzeichnis auf dieser Maschine ist jedoch ein symbolischer Link zu einem nicht standardmäßigen Speicherort, der nicht in der standardmäßigen AppArmor-Konfiguration aufgeführt ist. Der Zugriff ist unter erlaubt /home, aber der tatsächliche Speicherort meines Home-Verzeichnisses ist /elsewhere/home/gilles, daher wird der Zugriff verweigert.

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

  • Firefox, aber sein Profil iststandardmäß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 es nicht getestet, aber ich gehe davon aus, dass das Schreiben in fehlschlägt ~/PDF.

Meine Lösung bestand darin, /etc/apparmor.d/tunables/home.d/localdie Zeile zu bearbeiten und hinzuzufügen

@{HOMEDIRS}+=/elsewhere/home/

um den nicht standardmäßigen Speicherort der Home-Verzeichnisse erkennen zu lassen (beachten Sie, dass das Ende /wichtig ist; siehe die Kommentare in /etc/apparmor.d/tunables/home.d/ubuntu), und führen Sie dann 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, z. B. kopieren ~/bin. Sie wird dann nicht von der Apparmor-Richtlinie abgedeckt (Sie können sie also starten, profitieren jedoch nicht von der sehr begrenzten zusätzlichen Sicherheit, die Apparmor bietet).

Dieses Problem wurde gemeldet alsUbuntu-Fehler #447292. Die Lösung behandelt den Fall, in dem das Home-Verzeichnis einiger Benutzer als /etc/passwdaußerhalb aufgeführt ist /home, nicht jedoch Fälle wie meinen, in denen es /home/gillessich um einen symbolischen Link handelt.

Antwort2

Hatte das gleiche Problem und Ihre Antwort hat mich in die richtige Richtung gelenkt. Ich habe eine andere Lösung gefunden, bei der die Apparmor-Konfiguration nicht bearbeitet werden muss. Anstatt einen symbolischen Link zu verwenden, um den Zugriff auf umzuleiten /home, verwenden Sie die bindOption auf mount. Ich habe die folgende Zeile zu hinzugefügt /etc/fstab:

/elsewhere/home /home none bind

Sobald Sie dies tun, wird Apparmor nicht einmal wissen, dass sich die Verzeichnisse darunter /home„wirklich“ woanders befinden, und die Beschwerden werden daher verschwinden.

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

verwandte Informationen