English

[leonardofl]

The xauth will broke the container if you restart or poweroff the system, else in the same session will run ok, and not erase it.

Eu realmente não entendi o "else in the same session will run ok".

Você poderia, por favor, escrever aqui em português a frase toda, por favor? Daí eu mando um pull request melhorando o inglês.

Tks.

[farribeiro]

Falta concordância.

O xauth irá "quebrar" o container se você reiniciar ou desligar o sistema, senão na mesma sessão rodará ok se não apagá-lo.

[farribeiro]

@leonardofl Fiz um referencia de um issue porque deste aviso. Alguma dúvida a mais sobre o entendimento?

[leonardofl]

O xauth irá "quebrar" o container se você reiniciar ou desligar o sistema, senão na mesma sessão rodará ok se não apagá-lo.

Se não apagá-lo quem? O container? O XAuth? O que seria "apagar o xauth"?

[farribeiro]

O container.

Enquanto o xauth pertence ao sistema e que permite trazer a GUI ao hospedeiro, parte integrante do XOrg. Em outro issue, que referenciei aqui explicava o motivo deste PS. Mas em termos gerais, o xauth é um pedido do @lbssousa que dá camada de segurança extra ao servidor gráfico, mas não consegui reaproveitar o container em outras ocasiões.

Somente coloquei em português a frase, por gentileza, sugira melhoria na documentação. Com PR. Preferencia use inglês, pois seu objetivo neste projeto é para praticá-lo, para ter habilidade em projetos opensource afora que são comunicação oficial.

Grato

[lbssousa]

A respeito do xauth, você podes podem encontrar mais informações aqui: https://www.x.org/archive/X11R6.8.0/doc/xauth.1.html

O que acontece aqui é o seguinte: quando você faz login em uma sessão desktop comum no Linux, o gerenciador de login executa o Xorg em uma espécie de "modo autenticado" (vocês podem notar isso verificando a linha de comando do Xorg em um visualizador de processos: provavelmente vai ter algo como -auth /caminho/para/o/arquivo/de/autorização, onde este arquivo contém um token necessário para autorizar um aplicativo gráfico a rodar sobre aquela instância do Xorg). Dentro da sessão do usuário, este arquivo normalmente é referenciado pela variável de ambiente XAUTHORITY.

Para um programa gráfico qualquer rodar sobre um servidor Xorg específico, ambas as variáveis de ambiente DISPLAY e XAUTHORITY (se houver) precisam estar setadas com os valores correspondentes àquele servidor. Por outro lado, para liberar o acesso de qualquer aplicativo gráfico (mesmo sem XAUTHORITY definido) em um servidor Xorg autenticado, normalmente se executa o comando xhost + dentro da sessão do usuário (é o que se costuma fazer para executar um aplicativo gráfico como root dentro de uma sessão do usuário, por exemplo).

O que acontece no caso do Docker é que não dá pra aproveitar diretamente o arquivo XAUTHORITY da sessão do usuário no sistema hospedeiro, porque a estrutura de rede do container é separada do sistema hospedeiro (exceto se o container for invocado com a opção --net=host). O que se faz aqui, no caso, é pegar o token de autorização do Xorg do sistema hospedeiro e injetá-lo em um arquivo dentro do container (mesclando o token do sistema hospedeiro com as informações da rede interna do container) e passar este arquivo para o Firefox definindo a variável XAUTHORITY dentro do container.

O script que dispara o Firefox contido neste repositório contempla os dois casos, ou seja, funciona corretamente caso o container seja executado, ou não, com a opção --net=host.

[farribeiro]

@lbssousa A opção --net=host não é para interface de rede? Enquanto o volume é uma acesso a um determinado recuso/diretório dentro da maquina hospedeira, ou existe um FS de rede para o volumes, para o caso da XAUTHORITY?

Acredito eu que o docker não utiliza a interface docker0 ou semelhante, que estejam listado no docker network ls, para os volumes, salvo usando HA/SWARM. Enquanto sobre o "NAT" que o docker faz para acesso ao banco, o warsaw não reclama e nem bloqueia a conta na instituição, como muitos relatam quando acessa por VMs tradicionais em modo não-bridge.

Se necessário acredito podemos customizar uma rede a parte, e mandar pacotes XDMCP por ela, se for o caso, para o hospedeiro.

https://docs.docker.com/compose/networking/

[lbssousa]

Pelo que eu entendi daqui, a opção --net=host coloca o seu container na mesma rede do sistema hospedeiro, compartilhando o hostname, as inferfaces de rede, os sockets UNIX, etc. Neste modo, não é necessário, por exemplo, passar a opção -v /tmp/.X11-unix:/tmp/.X11-unix ao docker, pois o socket já é compartilhado. Neste modo, também é possível usar integralmente o arquivo XAUTHORITY do sistema hospedeiro, pois o hostname é compartilhado (bastaria um -v ${XAUTHORITY}:~/.Xauthority, por exemplo).

[farribeiro]

Tem o modo privileged que atribui o /dev e demais privilégios para o container, porém acho ruim em questão de isolamento. Não seria o mais correto?

[farribeiro]

Fechado pois o Issue desvirtuou ao seu assunto original. Debate continua em Issue #18