Acabei de notar algo peculiar sobre como sudo
lida com o .Xauthority
arquivo:
sudo xauth add $(xauth list | tail -1)
user@server: sudo xauth info
Authority file: /root/.xauthYZ21Nt
File new: no
File locked: no
Number of entries: 1
Changes honored: yes
Changes made: no
Current input: (argv):1
user@server: sudo xauth info
Authority file: /root/.xauth3BFy5d
File new: no
File locked: no
Number of entries: 1
Changes honored: yes
Changes made: no
Current input: (argv):1
user@server: sudo xauth list
server/unix:10 MIT-MAGIC-COOKIE-1 c922ab48defdf43b1092dffb86c06eed
user@server: sudo ls -la /root | grep auth
-rw-r--r-- 1 root root 0 Nov 9 14:40 .Xauthority
-rw------- 1 root root 57 Nov 9 15:23 .xauthsrxzxl
user@server: pkexec xauth info
Authority file: /root/.Xauthority
File new: no
File locked: no
Number of entries: 0
Changes honored: yes
Changes made: no
Current input: (argv):1
Portanto, $XAUTHORITY
value é diferente em cada new sudo
, e aponta para um arquivo temporário que desaparece quando sudo
sai. Por causa disso, o último comando (que usa pkexec
em vez de sudo
e espera que esteja em /root/.Xauthority
) não consegue ver o cookie. Por exemplo, sudo gedit
funciona bem, mas pkexec env DISPLAY=$DISPLAY gedit
falha.
Por que isso é feito de maneira tão complicada, onde os dados são armazenados e, mais importante, como posso acessar .Xauthority
os dados com pkexec
?
Quando um servidor X inicia com
-auth
a opção, ele cria um arquivo comMIT-MAGIC-COOKIE-1
(senha), e somente os usuários que conhecem essa senha podem exibir suas janelas no sistema X window.Pode haver mais de um
MIT-MAGIC-COOKIE-1
(net login,ssh -X
, ...), mas acho que no seu caso, se você verificar esses arquivos - eles terão exatamente o mesmo conteúdo (cmp /root/.xauth1 /root/.xauth2
).No entanto, se você iniciar um servidor X diferente e usar
sudo
(ousu
), a nova senha deverá ser diferente.Portanto, a razão para arquivos diferentes é porque
sudo
não sabia qual exibição é usada por outras instâncias e obtém as únicas senhas necessárias (e cria um novo arquivo para armazená-lo).O cookie xauth é armazenado nesse arquivo temporário (
~/.xauthXXXX
) que é removido quandosudo
retorna (por exemplo, quando osudo xauth info
comando termina).Sugiro que você dê uma olhada no código-fonte do
pam_xauth
módulo:Quanto ao
pkexec
, não acho que você deva executar aplicativos X11 com opkexec
. Já é ruim o suficiente que você possa executá-lossudo
;-)Tudo parece estar claro agora, obrigado @user499944. Resumidamente:
.xauthXXXXXX
os arquivos temporários são criados porpam_xauth
.eles só são criados se
$DISPLAY
estiver definido, que é o caso de ,sudo
mas não depkexec
. A execuçãopkexed env DISPLAY=$DISPLAY command
não leva a nada, porque$DISPLAY
só é definida após a conclusão da autenticação. Isso é revelado nos logs do sistema:Eu encontrei uma solução feia que permite
pkexec
executar corretamente copiando o cookie duas vezes:Ainda estou procurando a resposta para a pergunta original (onde os
xauth
dados dos arquivos temporários estão realmente armazenados?), o que espero que me permita usar o mesmo cookie para ambossudo
epkexec
comandos.Para responder à parte sobre por que
pam_xauth
armazena cada cookie em um arquivo separado, existem dois motivos:sudo
sessão, excluindo o arquivo.Em resumo: escopo e vida útil.