X11 apos sudo

sdiniz73
(usa Red Hat)

Enviado em 29/10/2021 - 14:44h

Pessoal, boa tarde! Tenho dois servidores RedHat com XFCE instalado. Configurado o Xrdp e o acesso via remote desktop, ocorre normalmente.

Só que no servidor novo, ao entrar com meu usuario (user1), consigo executar xclock normalmente e ao mudar de usuario (user2), o xclock da erro:

Invalid MIT-MAGIC-COOKIE-1 keyError: Can't open display: :10.0

Ai para contornar, viro root e copio o .Xauthoriy do user1 para o user2, mudo para o user2 e ai funciona.

Dúvida, teria como deixar automatico esse processo de copia do .Xauthority para todos os users?


Obrigado.

Bruuh
(usa Arch Linux)

Enviado em 29/10/2021 - 14:51h

Então cara, já tive um problema semelhante ao seu que dava esse erro do magic cookie. https://www.vivaolinux.com.br/topico/Linux-Tudo/Nao-consigo-fazer-login-no-arch-linux-em-modo-grafic...


Não tenho certeza, mas acredito que tu poderia fazer isso movendo o .Xauthority para o grupo dos usuários
Algo como:

sudo chown seuUsuario:seuGrupo .Xauthority  

Porém, acredito que isso só funcionaria se ambos os users, 1 e 2 estivessem no mesmo grupo.

sdiniz73
(usa Red Hat)

Enviado em 29/10/2021 - 16:56h

Saquei, vou testar.

paulo1205
(usa Ubuntu)

Enviado em 31/10/2021 - 20:24h

Não entendi o que você quer fazer. Para que “mudar de usuário”? Por que cada usuário não pode ter uma sessão independente do outro?

Ter um arquivo .Xauthority separado para cada usuário é uma questão de segurança. Compartilhar credenciais, mesmo através do mecanismo de autorização do X11, dá margem a vários tipos de ataques, incluindo keyloggers e outras formas de interceptação de sessão e de negação de serviço (por exemplo: um usuário exclui a credencial de segurança da sessão, e impede o outro de continuar trabalhando). Obviamente não é algo desejável em geral.

Para os casos em que compartilhar, exportar ou estender uma sessão do X11 pode ser desejável, uma maneira melhor de fazer do que usar o mesmo arquivo .Xauthority ou copiá-lo integralmente é extrair a credencial de sessão do usuário original e integrar a credencial extraída à lista de autorizações do segundo usuário.

# Sessão do usuário “user1” usando o display local “:0”.

# A linha em negrito contém informação de credencial da sessão corrente no display local “:0”.

user1$ xauth nextract - :0

0100 0011 686f7374312e6578616d706c652e636f6d 0001 30 0012 4d49542d4d414749432d434f4f4b49452d31 0010 e5e09087baaae480372419c1b21cec27 

# Sessão do usuário "user2".  Note que o argumento do comando echo é a mesma string em negrito acima.

# A credencial é agrgrada ao aruqivo .Xauthority do próprio user2, sem compartilhar todo o repositório de credenciais com user1.

user2$ echo "0100 0011 686f7374312e6578616d706c652e636f6d 0001 30 0012 4d49542d4d414749432d434f4f4b49452d31 0010 e5e09087baaae480372419c1b21cec27" | xauth nmerge -

# A partir de agora, user2 também pode usar o display local “:0” — inclusive com as implicações de segurança da sessão que isso tem. 

# Idealmente, quando user2 terminar de usar o recurso compartilhado, deveria excluí-lo de seu .Xauthority.

user2$ xauth remove :0 

Os passos acima podem ser arrumados como script sem muita dificuldade. Quando eu trabalhava com atendimento a usuários, eu cheguei a fazer um script que, usando a técnica acima, funcionava como um wrapper para o sudo, destinado a rodar comandos específicos como outro usuário dentro de uma sessão do X11.


... Então Jesus afirmou de novo: “(...) eu vim para que tenham vida, e a tenham plenamente.” (João 10:7-10)