Evince falha ao iniciar porque não consegue ler .Xauthority

Question

Estou logado remotamente por SSH com X encaminhamento para uma máquina rodando Ubuntu 10.04 (lúcido). A maioria das aplicações X11 (por exemplo, xterm, gnome-terminal) funcionam bem. Mas Evince não começa. Parece incapaz de ler ~/.Xauthority , mesmo que o arquivo exista e seja evidentemente legível (ele tem as permissões corretas e outros aplicativos o lêem bem).

$ 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

O que é tão especial sobre Evince que não consegue ler ~/.Xauthority ? Como posso começar?

    

Answer 1

TL, DR: é culpa do Apparmor, e devido ao meu diretório pessoal estar fora de /home .

Em uma instalação padrão do Ubuntu 10.04, o pacote apparmor é puxado como uma dependência indireta do nível de recomendação do pacote ubuntu-standard . Os logs do sistema ( /var/log/syslog ) mostram que o Apparmor está rejeitando a tentativa do Evince de ler ~/.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"

A configuração padrão do Evince para o Apparmor (em /etc/apparmor.d/usr.bin.evince ) é muito permissiva: permite leituras e gravações arbitrárias em todos os diretórios home. No entanto, meu diretório pessoal nesta máquina é um link simbólico para um local não padrão que não está listado na configuração padrão do AppArmor. O acesso é permitido em /home , mas o local real do meu diretório inicial é /elsewhere/home/gilles , portanto, o acesso é negado.

Outros aplicativos que podem ser afetados por esse problema incluem:

• Firefox, mas seu perfil é desativado por padrão (pela presença de um link simbólico /etc/apparmor.d/disable/usr.bin.firefox -> /etc/apparmor.d/usr.bin.firefox ).
• impressão em PDF CUPS; Eu não testei, mas espero que falhe em escrever para ~/PDF .

Minha correção foi editar /etc/apparmor.d/tunables/home.d/local e adicionar a linha

@{HOMEDIRS}+=/elsewhere/home/

para que o local não padrão dos diretórios pessoais seja reconhecido (observe que o% final/ é importante; veja os comentários em /etc/apparmor.d/tunables/home.d/ubuntu ), depois execute /etc/init.d/apparmor reload para atualizar as configurações do Apparmor.

Se você não tiver privilégios de administrador e o administrador do sistema não responder, você poderá copiar o binário evince para um local diferente, como ~/bin , e ele não será coberto pela política do Apparmor (para que você será capaz de iniciá-lo, mas não terá a segurança extra muito limitada que a Apparmor oferece).

Este problema foi reportado como erro do Ubuntu # 447292 . A resolução lida com o caso quando alguns usuários têm seu diretório home listado em /etc/passwd outside /home , mas não em casos como o meu, em que /home/gilles é um link simbólico.

    

Answer 2

Tive o mesmo problema e sua resposta me apontou na direção certa. Eu encontrei uma solução diferente, que não requer a edição da configuração do apparmor. Em vez de usar um symlink para redirecionar o acesso a /home , use a opção bind em mount . Eu adicionei a seguinte linha a /etc/fstab :

/elsewhere/home /home none bind

Uma vez que você fizer isso, o apparmor nem saberá que os diretórios sob /home estão "realmente" localizados em algum outro lugar, então as reclamações desaparecerão.

A vantagem dessa abordagem é que ela funcionará para todos os aplicativos, sem ter que editar um arquivo de configuração diferente do apparmor para cada um.