On 02/07/2018 04:10 PM, Matt Callaway wrote:
Hello,
I am attempting to run Docker on CentOS 7.4 with selinux and kernel
namespaces enabled. When I do so I observe an error that leads me to
an issue filed in github and a kernel patch that suggests that the
cause should be fixed in kernel 4.11+. Yet I cannot run docker
containers in this fashion on a 4.15 kernel.
Not sure what you mean by Kernel Namespace, are you talking about User
Namespace?
Should docker with selinux-enabled work on a 4.15.1 kernel on CentOS
7.4 with namespaces enabled?
Yes.
This might be a docker question, but the details I'll present below
suggest it might be more appropriate for this forum.
Details about the host and environment:
What AVC messages are you seeing?
[root@localhost ~]# uname -r
4.15.1-1.el7.elrepo.x86_64
[root@localhost ~]# cat /etc/redhat-release
CentOS Linux release 7.4.1708 (Core)
[root@localhost ~]# docker --version
Docker version 17.12.0-ce, build c97c6d6
This is the latest docker-ce package from Docker's repository:
[root@localhost ~]# repoquery -i docker-ce
Name : docker-ce
Version : 17.12.0.ce
Release : 1.el7.centos
Architecture: x86_64
Size : 128453687
Packager : Docker <support@xxxxxxxxxx>
Group : Tools/Docker
URL : https://www.docker.com
Repository : docker-ce-stable
Summary : The open-source application container engine
Source : docker-ce-17.12.0.ce-1.el7.centos.src.rpm
The kernel is 4.15.1 from ElRepo, because that seems to be the
accepted way to get a 4.x kernel on CentOS, which I did because data
suggested I needed at least 4.11+
[root@localhost ~]# repoquery -i kernel-ml
Name : kernel-ml
Version : 4.15.1
Release : 1.el7.elrepo
Architecture: x86_64
Size : 204626242
Packager : Alan Bartlett <ajb@xxxxxxxxxx>
Group : System Environment/Kernel
URL : https://www.kernel.org/
Repository : elrepo-kernel
Summary : The Linux kernel. (The core of any Linux-based operating system.)
Source : kernel-ml-4.15.1-1.el7.elrepo.src.rpm
Here we see selinux-enabled is true and userns-remap is set to default:
[root@localhost ~]# cat /etc/docker/daemon.json
{
"debug": true,
"selinux-enabled": true,
"userns-remap": "default"
}
[root@localhost ~]# docker info 2>&1 | grep -A3 Security
Security Options:
seccomp
Profile: default
selinux
So when I try it I get:
[root@localhost ~]# docker run hello-world
docker: Error response from daemon: OCI runtime create failed:
container_linux.go:296: starting container process caused
"process_linux.go:301: running exec setns process for init caused
\"exit status 40\"": unknown.
When running in Permissive mode I see a different error:
[root@localhost ~]# setenforce 0
[root@localhost ~]# docker run hello-world
docker: Error response from daemon: OCI runtime create failed:
container_linux.go:296: starting container process caused
"process_linux.go:398: container init caused \"rootfs_linux.go:58:
mounting \\\"devpts\\\" to rootfs
\\\"/var/lib/docker/1001.1001/overlay2/6798981d1cf925a748187e0f2e9151f47bca9352457aa5b933a2bcb55eff9570/merged\\\"
at \\\"/var/lib/docker/1001.1001/overlay2/6798981d1cf925a748187e0f2e9151f47bca9352457aa5b933a2bcb55eff9570/merged/dev/pts\\\"
caused \\\"invalid argument\\\"\"": unknown.
Looking around for these symptoms I find these references...
First message goes here:
https://github.com/moby/moby/issues/35336
Suggests the namespace.unpriv_enable=1 flag. I have already enabled that:
[root@localhost ~]# grep unpriv /boot/grub2/grub.cfg
linux16 /vmlinuz-4.15.1-1.el7.elrepo.x86_64
root=/dev/mapper/VolGroup00-LogVol00 ro no_timer_check console=tty0
console=ttyS0,115200n8 net.ifnames=0 biosdevname=0 crashkernel=auto
rd.lvm.lv=VolGroup00/LogVol00 rd.lvm.lv=VolGroup00/LogVol01 rhgb quiet
LANG=en_US.UTF-8 namespace.unpriv_enable=1
Then I do setenforce 0 and we get the second devpts error which leads to:
https://github.com/opencontainers/runc/issues/1215
which leads to:
https://bugzilla.redhat.com/show_bug.cgi?id=1401537
which leads to a kernel patch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=01593d3299a1cfdb5e08acf95f63ec59dd674906
I've since discovered via the author that that patch was included in
kernel 4.11.
So... what am I missing? All signs suggest that this *should* work,
and yet does not.
Thank you for your time.
