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

Estou logado remotamente pelo SSH com o encaminhamento do X para uma máquina executando o Ubuntu 10.04 (lucid). A maioria das aplicações X11 (por exemplo, xterm, gnome-terminal) funciona bem. Mas Evince não inicia. Parece incapaz de ler ~/.Xauthority, mesmo que o arquivo exista e é evidentemente legível (ele tem as permissões corretas e outros aplicativos o leem muito 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 há de tão especial no Evince que não consegue ler ~/.Xauthority? Como posso fazer isso começar?

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

Sob uma instalação padrão do Ubuntu 10.04, o pacote apparmor é extraído como uma dependência indireta no nível Recomendações 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 (in /etc/apparmor.d/usr.bin.evince) é muito permissiva: permite leituras e gravações arbitrárias em todos os diretórios pessoais . 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 a localização real do meu diretório pessoal é /elsewhere/home/gilles, portanto, o acesso é negado.

Outros aplicativos que podem ser afetados por esse problema incluem:

• Firefox, mas seu perfil está 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 do CUPS; Não testei, mas espero que falhe ao escrever ~/PDF.

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

@{HOMEDIRS}+=/elsewhere/home/

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

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

Este problema foi relatado como bug no Ubuntu # 447292 . A resolução lida com o caso quando alguns usuários têm seu diretório pessoal listado /etc/passwdfora /home, mas não casos como o meu, onde /home/gillesé um link simbólico.

Teve o mesmo problema, e sua resposta me apontou na direção certa. Encontrei uma solução diferente que não requer a edição da configuração do apparmor. Em vez de usar um link simbólico para o acesso redirecionamento para /home, use a bindopção mount. Eu adicionei a seguinte linha a /etc/fstab:

/elsewhere/home /home none bind

Depois que você fizer isso, o apparmor nem saberá que os diretórios abaixo /homeestão "realmente" localizados em outro lugar, de modo que as reclamações desaparecerão.

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