Evince nie uruchamia się, ponieważ nie może odczytać. Autoryzacja

Jestem zalogowany zdalnie przez SSH z X przekierowaniem na maszynę z Ubuntu 10.04 (lucid). Większość aplikacji X11 (np. Xterm, terminal gnome) działa dobrze. Ale Evince się nie zaczyna. Wydaje się, że nie jest w stanie odczytać ~/.Xauthority, nawet jeśli plik istnieje i jest wyraźnie czytelny (ma odpowiednie uprawnienia, a inne aplikacje czytają go dobrze).

$ 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

Co jest takiego specjalnego w Evince, że nie umie czytać ~/.Xauthority? Jak mogę to zacząć?

TL, DR: to wina Apparmora, a mój katalog domowy jest na zewnątrz /home.

W ramach domyślnej instalacji Ubuntu 10.04 pakiet apparmor jest pobierany jako pośrednia zależność na poziomie standardowym pakietu ubuntu . Logi systemowe ( /var/log/syslog) pokazują, że Apparmor odrzuca próbę odczytu Evince'a ~/.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"

Domyślna konfiguracja Evince dla Apparmor (in /etc/apparmor.d/usr.bin.evince) jest bardzo liberalna: pozwala na dowolne odczyty i zapisy we wszystkich katalogach domowych. Jednak mój katalog domowy na tym komputerze jest dowiązaniem symbolicznym do niestandardowej lokalizacji, która nie jest wymieniona w domyślnej konfiguracji AppArmor. Dostęp jest dozwolony pod /home, ale prawdziwa lokalizacja mojego katalogu domowego jest /elsewhere/home/gilles, więc odmowa dostępu.

Inne aplikacje, na które ten problem może mieć wpływ, to:

• Firefox, ale jego profil jest domyślnie wyłączony (przez obecność dowiązania symbolicznego /etc/apparmor.d/disable/usr.bin.firefox -> /etc/apparmor.d/usr.bin.firefox).
• Drukowanie PDF CUPS; Nie testowałem, ale spodziewam się, że nie powiedzie się to do pisania ~/PDF.

Moją poprawką było edytowanie /etc/apparmor.d/tunables/home.d/locali dodawanie linii

@{HOMEDIRS}+=/elsewhere/home/

aby rozpoznać niestandardową lokalizację katalogów domowych (pamiętaj, że finał /jest ważny; zobacz komentarze w /etc/apparmor.d/tunables/home.d/ubuntu), a następnie uruchom, /etc/init.d/apparmor reloadaby zaktualizować ustawienia Apparmor.

Jeśli nie masz uprawnień administratora, a administrator systemu nie odpowiada, możesz skopiować evinceplik binarny do innej lokalizacji, na przykład ~/bini nie będzie on objęty zasadami Apparmor (więc będziesz mógł go uruchomić, ale nie otrzyma bardzo ograniczonego dodatkowego bezpieczeństwa zapewnianego przez Apparmor).

Kwestia ta została zgłoszona jako bug # 447292 Ubuntu . Rozdzielczość obsługuje przypadek, gdy niektórzy użytkownicy mają swój katalog domowy wymieniony na /etc/passwdzewnątrz /home, ale nie przypadki takie jak mój, gdzie /home/gillesjest dowiązanie symboliczne.

Miałem ten sam problem, a twoja odpowiedź wskazała mi właściwy kierunek. Znalazłem inne rozwiązanie, które nie wymaga edycji konfiguracji aparatu. Zamiast używać dowiązania symbolicznego do przekierowywania dostępu /home, użyj bindopcji na mount. Dodałem następujący wiersz do /etc/fstab:

/elsewhere/home /home none bind

Gdy to zrobisz, apparmor nie będzie nawet wiedział, że katalogi /homeznajdujące się „naprawdę” znajdują się gdzie indziej, więc skargi znikną.

Zaletą tego podejścia jest to, że będzie działać dla wszystkich aplikacji, bez konieczności edytowania innego pliku konfiguracyjnego Apparmor dla każdego z nich.