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

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

Estou logado remotamente via SSH com encaminhamento de X para uma máquina rodando Ubuntu 10.04 (lúcido). A maioria dos aplicativos X11 (por exemplo, xterm, gnome-terminal) funciona bem. Mas Evince não inicia. 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 leem perfeitamente).

$ 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 ele não consegue ler ~/.Xauthority? Como posso fazer isso começar?

Responder1

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

Sob uma instalação padrão do Ubuntu 10.04, oaparelhopacote é obtido como uma dependência indireta de nível de recomendação dopadrão Ubuntupacote. Os logs do sistema ( /var/log/syslog) mostram que o Apparmor está rejeitando a tentativa de leitura do Evince ~/.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 Apparmor (in /etc/apparmor.d/usr.bin.evince) é muito permissiva: permite leituras e gravações arbitrárias em todos os diretórios iniciais. No entanto, meu diretório inicial 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 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 de PDF CUPS; Não testei, mas espero que falhe ao gravar em ~/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 iniciais seja reconhecido (observe que o 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, você pode 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 o Apparmor oferece).

Este problema foi relatado comoBug do Ubuntu #447292. A resolução trata do caso em que alguns usuários têm seu diretório inicial listado em /etc/passwdoutside /home, mas não de casos como o meu, onde /home/gilleshá um link simbólico.

Responder2

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

/elsewhere/home /home none bind

Depois de fazer isso, o apparmor nem saberá que os diretórios abaixo /homeestão "realmente" localizados em outro lugar, então 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 de apparmor diferente para cada um.

informação relacionada