Estoy intentando ejecutar un contenedor en un RHEL 6.5 pero sigo teniendo 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
Cuando se ejecuta como usuario 'root', el contenedor se inicia bien pero el problema vuelve a aparecer al intentar cambiar a otro usuario:
$ sudo docker run -u root -it registry/database /bin/bash
[root@8a20410eaa5e /]# su postgres
su: /bin/bash: Permission denied
Este es un contenedor específico creado por nosotros, basado en CentOS 6.5 y que ejecuta Postgres. El Dockerfile para compilarlo tiene "USER postgres" y funciona bien en otros lugares excepto en estos servidores. Puedo reproducir el mismo comportamiento con un contenedor de caja ocupada:
$ sudo docker run -u nobody -it 10.188.13.136:8080/busybox
/ $ ls
/bin/sh: ls: Permission denied
El host RHEL 6.5 tiene SELinux habilitado. Tenemos otros hosts donde SELinux y este contenedor funcionan bien allí. El registro de auditoría de este host parece limpio, no puedo ver mensajes de error al intentar ejecutar el contenedor.
Esto es lo que hemos probado hasta ahora:
- actualizar las políticas de SELinux en RHEL ("sudo yum Upgrade selinux-policy"), ya que no eran las últimas versiones
- poner SELinux en modo permisivo (setenforce 0); No intenté apagarlo por completo y reiniciar
- inicie el demonio Docker con "--selinux-enabled=true"
- iniciar el contenedor con --privilegiado
- inicie el contenedor con --security-opt=:label:disable
- Estamos ejecutando el último kernel RHEL 6.5: 2.6.32-504.16.2.el6.x86_64
También ejecute una sesión strace para el comando 'su ' dentro del contenedor pero no pude ver mucho más allá de esto:
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
El volcado completo de strace está aquí en caso de que sea necesario:http://pastebin.com/42C2B8LP.
No estamos seguros de qué buscar a continuación, ¿alguna idea?
Respuesta1
Finalmente pude resolver este problema. Lo que significa que parece que encontré una solución, pero todavía no estoy seguro de cuál es el problema:
1) extraer el contenedor del registro 2.0 + ejecutar con Docker 1.6 -> fallar
2) extraer el contenedor del registro 0.9.x (ya sea el de Docker o el servidor Artifactory que ejecutamos internamente) + ejecutar con Docker 1.6 -> funciona
3) extraer el contenedor del registro 2.0 + ejecutar con Docker 1.5 o anterior -> fallar
4) extraer el registro del formulario del contenedor 0.9.x + ejecutar con Docker 1.5 o posterior -> funciona
Realmente no creo que el Registro 2.0 tenga la culpa, pero no tengo una mejor respuesta. El nuevo registro es mucho más rápido que el anterior, pero supongo que por el momento nos quedaremos con el registro anterior.