Evince non si avvia perché non è in grado di leggere .Xauthority


10

Ho effettuato l'accesso in remoto tramite SSH con X forwarding a una macchina che esegue Ubuntu 10.04 (lucido). La maggior parte delle applicazioni X11 (ad es. Xterm, gnome-terminal) funzionano bene. Ma Evince non parte. Sembra incapace di leggere ~/.Xauthority, anche se il file esiste ed è evidentemente leggibile (ha i permessi giusti e altre applicazioni lo leggono bene).

$ 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

Cosa c'è di così speciale in Evince che non sa leggere ~/.Xauthority? Come posso farlo iniziare?

Risposte:


12

TL, DR: è colpa di Apparmor, e perché la mia directory home è fuori /home.

Sotto un'installazione predefinita di Ubuntu 10.04, il pacchetto apparmor viene inserito come una dipendenza indiretta a livello di Raccomandazione del pacchetto ubuntu-standard . I registri di sistema ( /var/log/syslog) mostrano che Apparmor sta rifiutando il tentativo di Evince di leggere ~/.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 configurazione predefinita di Evince per Apparmor (in /etc/apparmor.d/usr.bin.evince) è molto permissiva: consente letture e scritture arbitrarie in tutte le home directory. Tuttavia, la mia home directory su questa macchina è un collegamento simbolico a una posizione non standard che non è elencata nella configurazione AppArmor predefinita. L'accesso è consentito in /home, ma la posizione reale della mia home directory è /elsewhere/home/gilles, quindi l'accesso è negato.

Altre applicazioni che potrebbero essere interessate da questo problema includono:

  • Firefox, ma il suo profilo è disabilitato per impostazione predefinita (dalla presenza di un collegamento simbolico /etc/apparmor.d/disable/usr.bin.firefox -> /etc/apparmor.d/usr.bin.firefox).
  • Stampa PDF CUPS; Non ho ancora testato, ma mi aspetto che non riesca a scrivere ~/PDF.

La mia correzione era quella di modificare /etc/apparmor.d/tunables/home.d/locale aggiungere la linea

@{HOMEDIRS}+=/elsewhere/home/

per riconoscere la posizione non standard delle home directory (notare che il finale /è importante; vedere i commenti in /etc/apparmor.d/tunables/home.d/ubuntu), quindi eseguire /etc/init.d/apparmor reloadper aggiornare le impostazioni di Apparmor.

Se non si dispone dei privilegi di amministratore e l'amministratore di sistema non risponde, è possibile copiare il file evincebinario in una posizione diversa, ad esempio ~/bin, e non sarà coperto dalla politica di Apparmor (quindi sarà possibile avviarlo, ma non sarà garantita la sicurezza extra molto limitata fornita da Apparmor).

Questo problema è stato segnalato come bug # 447292 di Ubuntu . La risoluzione gestisce il caso in cui alcuni utenti hanno la loro home directory come elencata /etc/passwdall'esterno /home, ma non casi come il mio in cui /home/gillesè presente un collegamento simbolico.


Grazie. In Ubuntu 16.04, il file pertinente è '/etc/apparmor.d/tunables/home.d/ubuntu' e si raccomanda che invece di modificarlo manualmente, si esegua: 'sudo dpkg-reconfigure apparmor' (che ti darà l'opportunità di aggiungere posizioni di casa)
arr_sea

2

Ho avuto lo stesso problema e la tua risposta mi ha indicato la giusta direzione. Ho trovato una soluzione diversa che non richiede la modifica della configurazione di Apparmor. Invece di utilizzare un collegamento simbolico per reindirizzare l'accesso /home, utilizzare l' bindopzione su mount. Ho aggiunto la seguente riga a /etc/fstab:

/elsewhere/home /home none bind

Una volta che lo fai, l'apparmor non saprà nemmeno che le directory sotto si /hometrovano "davvero" da qualche altra parte, quindi i reclami spariranno.

Il vantaggio di questo approccio è che funzionerà per tutte le applicazioni, senza dover modificare un file di configurazione apparmor diverso per ognuna.


1
Questo non sarebbe stato applicabile nel mio caso: c'erano sotto home directory /homee altre no /home. Una variante per questo caso è legare-mount /elsewhere/home/gillesa /home/gilles, o /elsewhere/homea /home/elsewhere.
Gilles 'SO- smetti di essere malvagio'
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.