Por que não consigo executar aplicativos GUI a partir de 'root': “Nenhum protocolo especificado”?

Instalei o debian na minha máquina ontem à noite. Agora, não entendo por que não consigo executar aplicativos GUI de um terminal ao executar como root.

Por exemplo:

sudo -i
glxgears

Gera a seguinte saída:

No protocol specified
Error: couldn't open display :0

Mas quando eu abro o terminal, posso executar a glxgearspartir da conta do usuário. É só depois que eu faço sudo -ique o problema surge. Isso acontece para qualquer aplicativo GUI que eu tente executar. Eu acho que provavelmente está relacionado ao X11, mas não tenho certeza.

O acesso ao servidor X requer duas coisas:

• A $DISPLAYvariável que aponta para a exibição correta (geralmente :0)
• Informações de autenticação adequadas

As informações de autenticação podem ser especificadas explicitamente via $XAUTHORITYe o padrão é o ~/.Xauthoritycontrário.

Se $DISPLAYe $XAUTHORITYestiver definido para o usuário, também sudoserá definido para o novo shell, e tudo deve funcionar bem.

Se eles não estiverem configurados, provavelmente serão padronizados com os valores incorretos e você não poderá iniciar e X aplicativos.

No Debian, $XAUTHORITYgeralmente não é definido explicitamente. Basta adicionar

export XAUTHORITY=~/.Xauthority

ao seu .bashrcou diga explicitamente XAUTHORITY=~/.Xauthority sudo ...e tudo deve funcionar.

Você também pode usar xauth listpara verificar se as informações de autenticação adequadas estão disponíveis.

Eu tive a mesma pergunta que você, mas para um usuário normal. Digamos que eu queira iniciar o Firefox usando a conta de usuário foo. Estou logado como barra:

[bar@localhost ~]$ sudo -u foo -H firefox

Infelizmente esse comando falhou com o mesmo erro da pergunta (ou seja, nenhum protocolo especificado e não pode abrir a tela)

Minha solução foi simplesmente adicionar o usuário foo à lista de acesso autorizado ao servidor X.

xhost si:localuser:foo

E foi isso, então eu pude iniciar o Firefox (e outro aplicativo X) usando sudoe o usuário foo.

Antecedentes : Na janela X, há uma arquitetura cliente / servidor. Ao iniciar um aplicativo, você solicita a autorização do servidor X para exibi-lo. Por padrão, depois de abrir uma sessão (você loga graficamente), você (seu usuário) obviamente tem permissão para se comunicar com o servidor e exibir aplicativos. Outros usuários não têm essa permissão, a menos que você a especifique. xhosté uma ferramenta para manipular a lista de permissões. A siindica que a regra é do lado do servidor e autorizar o usuário local foopara aplicações de display. O X Window é muito poderoso nesse sentido e você pode exibir aplicativos remotos localmente jogando com a DISPLAYvariável de ambiente e xhost(mas não se limitando a eles). Antigamente, quando as pessoas digitavamxhost + e implicitamente permitiu que todos usassem sua sessão X, era possível exibir aplicativos em suas telas para brincadeiras ;-) não tanto hoje em dia quanto as pessoas usam cada vez menos a arquitetura cliente / servidor do X Window (pelo menos pelo que observo no últimos 10 anos).

PS: Fiz isso para iniciar o Firefox em uma espécie de "prisão" (para evitar uma vulnerabilidade como o pdf.js no futuro). Mas descobri rapidamente que chamar o Firefox via sudo não permitirá que ele acesse o áudio nem o hardware de vídeo. Mas há um cara que explica claramente como ativar a aceleração e o áudio do hardware de vídeo ao chamar o Firefox via sudo . YMMV com estas instruções, por exemplo, ainda tenho uma permissão negada com áudio, mas o vídeo é bom (testado no Fedora 22 com o SELinux ON).

Você também pode

Especifique a exibição a ser usada na linha de comandos, adicionando -display :0.0

ou

Configure a variável de ambiente no script de login da raiz (um dos arquivos .bashrc, .profile, .bash_profile ...).

export DISPLAY=:0.0

Você pode verificar se está definido,

$ env |grep DISPLAY
DISPLAY=:0.0

Para abrir sua exibição para todos os usuários de todos os hosts como seu usuário normal, você pode fazer isso com:

xhost +

Dado que você está no Debian, a solução simples e suportada é organizar para sudocopiar suas credenciais de autorização X11. pam_xauthestá incluído no libpam-modulespacote exatamente para esse fim; para usá-lo, você só precisa adicionar

session  optional  pam_xauth.so

para o seu /etc/pam.d/sudoarquivo. Você também pode optar por adicioná-lo sutambém. Para informações completas, consulte a pam_xauthpágina do manual, é claro.

O que me ajudou:

1. Você pode xauth generate :0 . trusteddo userlado, o que irá gerar um novoMIT-MAGIC-COOKIE-1

2. Verifique se a chave recém-criada, com a variável xAuthority da raiz do xauth list' asusuário, está apontando para o mesmo arquivo.and(they should be the same if your

3. Voila, rootacessará qualquer um X-Appdo terminal, mas apenas temporariamente.

Para torná-lo permanente, consulte a resposta de @Huygens!

Solução alternativa :

Serviços como o cron em execução no root não têm acesso para exibição se o usuário x atual não for root.

Nós só precisamos adicionar o usuário root ao x, você pode fazê-lo no momento do login com um script de inicialização

xhost local:root

Para fins de teste, podemos simplesmente executar than command sob o usuário atual e reiniciar o script raiz / job / service / ...

O sudocomando possui uma opção para preservar variáveis ​​de ambiente.

 -E, --preserve-env            preserve user environment when running command

Para que você possa executar o comando com a opção -E. Exemplo:

sudo -E wireshark

Se você não precisar executar aplicativos críticos de privacidade, como navegadores da web, será melhor adicionar a opção -E ao sudo. Não podemos executar o Chrome ou o Firefox apenas adicionando a opção -E . Porque muitos navegadores implementaram proteção contra violações do espaço do usuário. A resposta de @ huygens pode ter informações sobre esse assunto.

Nota: A adição da opção -E não ajudará se o ambiente do usuário NÃO tiver DISPLAY e XAUTHORITY já estiver definido corretamente .

use este comando e funcionará

sudo cp /home/user/.Xauthority .Xauthority