Como resolver 'Nenhum protocolo especificado' para o usuário su

Question

Estou tentando usar um usuário alternativo (não administrador) para executar software gráfico no meu sistema. Esse usuário alternativo foi nomeado e recebeu um UID e GID para corresponder a um usuário do sistema remoto com o mesmo nome. O UID é 500, então acredito que isso torne o usuário um usuário 'não-login'.

A partir do Ubuntu logado na minha conta principal, eu abro um terminal e su para o usuário alternativo. Eu então tento executar o comando para iniciar o aplicativo e receber 'Nenhum protocolo especificado'.

É por causa do UID < 1000, por causa do su ou do não-administrador do usuário? Como posso fazer esse usuário executar o aplicativo com uma GUI?

    

Answer 1

O problema é que não ocorre por causa do UID do usuário. 500 é bom como um UID, e esse UID não o torna um usuário 'não-login', exceto aos olhos das configurações padrão de alguns poucos gerenciadores de exibição.

A mensagem de erro Nenhum protocolo especificado soa como uma mensagem de erro específica do aplicativo e não é útil, mas adivinho que o erro é que o aplicativo não consegue contatar o seu O X11 é exibido porque não tem permissão para isso porque está sendo executado como um usuário diferente. As aplicações precisam de um "magic cookie" (token secreto) para poderem conversar com o servidor X11, de modo que outros processos no sistema rodando sob outros usuários não possam interferir em seu monitor, criar janelas e bisbilhotar seus toques de tecla. O outro usuário do sistema não tem acesso a esse cookie mágico porque as permissões são definidas para que seja acessível apenas ao usuário que iniciou o ambiente de área de trabalho (que é como deveria ser).

Tente isso, executando como seu usuário original, para copiar o cookie X11 para a outra conta:

su - <otheruser> -c "unset XAUTHORITY; xauth add $(xauth list)"

execute seu aplicativo. Você também pode precisar desabilitar XAUTHORITY nesse shell também. Esse comando extrai o cookie mágico ( xauth list ) do seu usuário principal e o adiciona ( xauth add ) ao local onde o outro usuário pode obtê-lo.

    

Answer 2

Tente algo assim

$ export LOGIN_USER="Math"
$ su - $LOGIN_USER
$ sudo xhost local:$LOGIN_USER &>/dev/null

fonte

Ps : a resposta aceita não funcionou para mim

    

Answer 3

Suponha que você queira força bruta obter uma conexão com o X ...

Vamos supor que você já esteja executando seus comandos no servidor (onde o X roda), caso contrário, trabalhe primeiro e, em seguida, use 'ssh -X user @ server) do cliente;).

Pode haver várias maneiras de executar os comandos xauth, por exemplo, você pode estar usando 'sudo', mas isso pode perder ou alterar variáveis de ambiente. As seguintes variáveis de ambiente precisam ser preservadas: DISPLAY e XAUTHORITY. Para testar se esse é o caso, você pode executar 'echo $ XAUTHORITY' da mesma forma que executa seus comandos, mas certifique-se de não expandir as variáveis de ambiente antes de executar esses comandos. Por exemplo, tente: sudo bash -c echo "$ XAUTHORITY" 'para ver o que realmente é XAUTHORITY depois de executar o seu sudo (se ele desaparecer, você pode precisar adicionar algo ao seu arquivo sudoers, veja em outro lugar).

Eventualmente, execute o seguinte comando como o usuário com o qual você deseja obter acesso, no servidor:

xauth info

Isto mostrará o 'arquivo de autoridade' que será usado (/root/.Xauthority por padrão, para root, ou algo como /home/theuser/.Xauthority). Se ele mostrar o arquivo .Xauthority correto, você não precisa se preocupar com a variável de ambiente XAUTHORITY (na verdade, eu não saberia quando isso não aconteceria, exceto se você quiser manipular um local não padrão desse arquivo ).

Remova esse arquivo (se existir):

rm /root/.Xauthority

Substitua /root/.Xauthority pelo arquivo XAUTHORITY correto para o seu caso.

Recrie-o, mas vazio (isso é necessário para muitos comandos):

touch /root/.Xauthority

Neste ponto, você receberá o erro Nenhum protocolo especificado , mesmo que tenha MIT-MAGIC-COOKIE-1 inválido antes. Encontre o arquivo de autoridade que o servidor X está usando no momento:

ps aux | grep Xorg

Isso deve mostrar algo como:

root 1153 0.0 1.0 149560 44464 tty7 Ss+ dec02 0:00 /usr/lib/xorg/Xorg -nolisten tcp -auth /var/run/sddm/{ef18c483-7891-4e82-80ef-2c8f9bd79711} -background none -noreset -displayfd 17 vt7

O nome do arquivo após -auth é o que você precisa no próximo comando. Execute isso como root:

sudo xauth -f '/var/run/sddm/{ef18c483-7891-4e82-80ef-2c8f9bd79711}' list

Isso lista uma chave hexadecimal de 32 dígitos. Por exemplo, a saída poderia ser:

hostname/unix:0 MIT-MAGIC-COOKIE-1 c0eaf749aa252101a0f57d5087089db7

Use isso para gerar seu arquivo .Xauthority (como usuário que precisa fazer o login novamente):

xauth add $DISPLAY MIT-MAGIC-COOKIE-1 c0eaf749aa252101a0f57d5087089db7

substitua 'c0eaf749aa252101a0f57d5087089db7' pelo que foi retornado pelo comando list para você. Agora sua autoridade X deve ter 51 bytes e você pode se conectar ao servidor X novamente.

    

Answer 4

No meu caso, o novo servidor de exibição wayland foi o problema, basta fazer xhost + local: , em seguida, outros usuários (por exemplo, raiz) têm permissão para executar os programas em sua sessão.

    

Answer 5

Eu tive este erro "Nenhum protocolo especificado" quando iniciei uma instância do Selenium 3.3.1 de um script upstart e usei o driver do Chrome no Selenium. O selênio foi executado como o mesmo usuário do X11 e a variável de ambiente do shell DISPLAY foi definida corretamente. O interessante é que esse erro não aconteceu quando usei o driver do Firefox. A configuração da variável de ambiente shell XAUTHORITY dentro do script upstart para apontar para o valor de $ XAUTHORITY do usuário X11 ativo corrigiu o erro para o driver do Chrome.

Em uma nota lateral, o erro "Nenhum protocolo especificado" foi totalmente inserido pelo driver Chrome / Chrome e não foi de maneira alguma fácil de ser encontrado. Percebi que o Chrome continuava criando diretórios no padrão de /tmp/.org.chromium.Chromium.* , mas eles estavam rapidamente desaparecendo. Eu consegui perceber que eles continham um arquivo chrome_debug.log que tinha uma mensagem "Não é possível abrir a tela". Eu percebi que isso era um pouco estranho, já que verifiquei que o processo Selenium tinha o DISPLAY correto em /proc/$pid/environ e examinei a saída de strace no processo Selenium mais detalhadamente, que revelou "Nenhum protocolo especificado" levando-me eventualmente a essa questão .

Este erro pode ser reproduzido desativando XAUTHORITY e tentando executar algum cliente X11. Por exemplo:

$ XAUTHORITY= xeyes
No protocol specified
Error: Can't open display: :0.0

    

Answer 6

Isso foi simples. O problema acontece quando você está no estado raiz e quer usar o gksu Basta sair do estado raiz e tentar novamente

    

Answer 7

Basta digitar isso no seu terminal xhost +SI:localuser:root depois que você digitar export DISPLAY=:0.0 e tentar novamente

    

Answer 8

Usando dicas nas respostas aceitas, consegui resolver o problema de forma diferente:

1. Localize o arquivo Xauth na conta que funciona (Xauth1)
2. Localize o arquivo Xauth na conta que não faz (Xauth2)
3. Copie Xauth1 para Xauth2
4. Alterar as permissões do Xauth2

no código:

root@45c4933a8f1a:~# xauth info
Authority file:       /headless/.Xauthority
<snip>
root@45c4933a8f1a:~# su OtherUser
OtherUser@45c4933a8f1a:/headless$ xauth info
Authority file:       /home/OtherUser/.Xauthority
<snip>
OtherUser@45c4933a8f1a:/headless$ exit
exit
root@45c4933a8f1a:~# cp /headless/.Xauthority /home/OtherUser/.Xauthority 
root@45c4933a8f1a:~# chown OtherUser:OtherUser /home/OtherUser/.Xauthority
root@45c4933a8f1a:~# su OtherUser