Chrome no Docker: CAP_SYS_ADMIN x privilegiado? [fechadas]

11

Fechadas. Esta questão está fora de tópico . No momento, não está aceitando respostas.

Deseja melhorar esta pergunta? Atualize a pergunta para que ela esteja no tópico sobre Falha no servidor.

Fechado há 10 meses .

Estou executando o chromedriver + chrome no Docker no meu ambiente de teste.

Tudo estava funcionando bem até a atualização mais recente do CoreOS.

Estas são as versões que parecem funcionar:

VERSION=1185.5.0
VERSION_ID=1185.5.0
BUILD_ID=2016-12-07-0937

E esta é uma versão mais recente que faz com que o chrome coredump:

VERSION=1235.4.0
VERSION_ID=1235.4.0
BUILD_ID=2017-01-04-0450

Observando as mudanças, parece que o docker foi atualizado de 1.11.x para 1.12.x, que interrompeu a setns()chamada dentro do contêiner. setns()é usado pelo Chrome para criar espaços para nome.

Estes são os exemplos de saídas:

jsosic-coreos-test-20161207 ~ # docker --version
Docker version 1.11.2, build bac3bae

De dentro de um contêiner nesta caixa:

[root@2939f21ecfaa /]# /opt/google/chrome/google-chrome
[57:57:0107/015130:ERROR:browser_main_loop.cc(261)] Gtk: cannot open display:

É assim que a nova versão o quebrou:

jsosic-coreos-test-2017-01-04 ~ # docker --version
Docker version 1.12.3, build 34a2ead

[root@13ab34c36c82 /]# /opt/google/chrome/chrome
Failed to move to new namespace: PID namespaces supported,
  Network namespace supported,
  but failed: errno = Operation not permitted
Aborted (core dumped)

O que descobri é que, se eu iniciar o contêiner com --cap-add=SYS_ADMINou --privileged- o Chrome funcionará conforme o esperado.

Qual é a diferença entre esses dois switches? Quais recursos são ativados por --privileged?

E posso permitir o setns()contêiner interno sem comprometer a segurança?

— Jakov Sosic
fonte

Obrigado por isso. Fiz um problema, usando um monte de seu material: github.com/docker/for-linux/issues/496 Eu acho que deveria ficar fixo

— Merc

Estou quase dois anos atrasado, mas há uma solução muito melhor e mais segura no ticket acima, se você ainda estiver interessado.

— Merc

Se o pôster original não atualizar a resposta (ele não parece ativo no SO), deixe-me saber se você estaria disponível para aceitar uma resposta diferente. Eu perdi horas com isso, só posso imaginar quantas horas salvaremos outras pessoas.

— Merc

7

AFAICS, a documentação sugere conceder os recursos necessários para um contêiner, em vez de usar o --privilegedcomutador. A execução no modo privilegiado parece conceder ao contêiner todos os recursos (exatamente os que estão listados no primeiro URL, desde que os documentos estejam atualizados).

Em resumo, eu diria que --cap-add=SYS_ADMINconcede um subconjunto menor de recursos ao contêiner, comparado ao --privilegedswitch. Caso os exemplos na documentação do Docker (primeira URL) pareçam preferir apenas adicionar o recurso SYS_ADMINou NET_ADMINquando necessário.

— ivuk
fonte

Obrigado, exec_linux.goajudou. Tentei clonagem repo janela de encaixe para grep através dele, mas desde que ele me levou duas horas Eu apenas esqueci :)

— Jakov Sosic

Apenas para executar o Chrome, há uma solução muito melhor listada aqui: github.com/docker/for-linux/issues/496#issuecomment-441149510 Acho que seria muito benéfico atualizar a resposta para que as pessoas façam o que eu explico em esse mesmo comentário. Entre em contato se você concordar.

— Merc

1

Uma diferença é que --privileged monta / dev e / sys como RW, onde SYS_ADMIN os monta como RO. Isso significa que um contêiner privilegiado tem acesso total aos dispositivos no sistema. SYS_ADMIN não fornece isso a você.

— mel1990
fonte