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/local
e 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 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ê pode copiar o evince
biná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/passwd
outside /home
, mas não de casos como o meu, onde /home/gilles
há 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 bind
opçã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 /home
estã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.