☰

Docker 1.6.0 no RHEL 6.5 com SELinux, não é possível executar contêineres sem root

tag-icon • tag-icon rhel6 docker selinux
Docker 1.6.0 no RHEL 6.5 com SELinux, não é possível executar contêineres sem root

Estou tentando executar um contêiner em um RHEL 6.5, mas continuo enfrentando este problema:

sudo docker run -u postgres -it registry/postgres /bin/bash
/bin/bash: error while loading shared libraries: libtinfo.so.5: cannot open shared object file: Permission denied

Quando executado como usuário 'root', o contêiner inicia bem, mas o problema aparece novamente ao tentar mudar para outro usuário:

$ sudo docker run -u root -it registry/database /bin/bash
[root@8a20410eaa5e /]# su postgres
su: /bin/bash: Permission denied

Este é um contêiner específico construído por nós, baseado em CentOS 6.5 e que roda Postgres. O Dockerfile para construí-lo contém "USER postgres" e funciona bem em outros lugares, exceto nesses servidores. Posso reproduzir o mesmo comportamento com um contêiner busybox:

$ sudo docker run -u nobody -it 10.188.13.136:8080/busybox
/ $ ls
/bin/sh: ls: Permission denied

O host RHEL 6.5 tem o SELinux habilitado. Temos outros hosts onde o SELinux e este contêiner funcionam bem. O log de auditoria deste host parece limpo, sem mensagens de erro que eu possa ver ao tentar executar o contêiner.

Isto é o que tentamos até agora:

  • atualize as políticas SELinux no RHEL ("sudo yum upgrade selinux-policy"), pois não eram as versões mais recentes
  • coloque o SELinux em modo permissivo (setenforce 0); não tentei desligá-lo completamente e reiniciar
  • inicie o daemon Docker com "--selinux-enabled=true"
  • inicie o contêiner com --privileged
  • inicie o contêiner com --security-opt=:label:disable
  • estamos executando o kernel RHEL 6.5 mais recente: 2.6.32-504.16.2.el6.x86_64

Execute também uma sessão strace para o comando 'su' dentro do contêiner, mas não conseguiu ver muito além destes:

 17    setgid(10000)                     = 0
 17    setuid(10000)                     = 0
 17    munmap(0x7f07a3540000, 2101304)   = 0
 17    munmap(0x7f07a311c000, 2113776)   = 0
 17    munmap(0x7f07a2f03000, 2196352)   = 0
 17    munmap(0x7f07a2cea000, 2198192)   = 0
 17    munmap(0x7f07a2ae8000, 2101272)   = 0
 17    munmap(0x7f07a28e4000, 2109624)   = 0
 17    munmap(0x7f07a26e0000, 2109672)   = 0
 17    munmap(0x7f07a24d3000, 2148896)   = 0
 17    munmap(0x7f07a22d0000, 2105488)   = 0
 17    munmap(0x7f07a20cb000, 2113848)   = 0
 17    munmap(0x7f07a1ec5000, 2118168)   = 0
 17    munmap(0x7f07a3321000, 2221912)   = 0
 17    execve("/bin/bash", ["bash"], [/* 15 vars */]) = -1 EACCES (Permission denied)
 17    write(2, "su: ", 4)               = 4
 17    write(2, "/bin/bash", 9)          = 9

O dump completo do strace está aqui caso seja necessário:http://pastebin.com/42C2B8LP.

Não temos certeza do que procurar a seguir, alguma ideia?

Responder1

Finalmente consegui resolver esse problema. O que significa que parece que encontrei uma solução, mas ainda não tenho certeza de qual é o problema:

1) extrair contêiner do registro 2.0 + executar com docker 1.6 -> falhar

2) extrair o contêiner do registro 0.9.x (do próprio Docker ou do servidor Artifactory que executamos internamente) + executar com o docker 1.6 -> funciona

3) extrair o contêiner do registro 2.0 + executar com docker 1.5 ou anterior -> falhar

4) extraia o registro do formulário do contêiner 0.9.x + execute com docker 1.5 ou mais recente -> funciona

Eu realmente não acho que o Registry 2.0 seja o culpado, mas não tenho uma resposta melhor. O novo registro é muito mais rápido que o antigo, mas acho que ficaremos com o registro antigo por enquanto.

informação relacionada