process_linux.go:252: getting pipe fds for pid 2130 caused "readlink /proc/2130/fd/0: permission denied"

[anevenchanniy]

Unable to start docker container inside unprivilegied LXC container with error:

[root@klxc5 /]# docker run --rm -it registry.foo.bar/base/centos:7.3.1611 /bin/bash
docker: Error response from daemon: oci runtime error: container_linux.go:247: starting container process caused "process_linux.go:252: getting pipe fds for pid 2130 caused "readlink /proc/2130/fd/0: permission denied"".

LXC version: 2.0.7
OS: CentOs-7.3

LXC container config:

lxc.arch = x86_64
lxc.id_map = u 0 165536 65536
lxc.id_map = g 0 165536 65536
lxc.cgroup.devices.allow = a
lxc.cap.drop = mac_admin mac_override sys_time sys_module sys_rawio
lxc.aa_profile = unconfined
lxc.rootfs = /dev/vg00/klxc5.cloud.foo.bar
lxc.rootfs.backend = lvm
lxc.utsname = klxc5.cloud.foo.bar
lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = k8sbr
lxc.network.ipv4 = x.x.x.x/21
lxc.network.ipv4.gateway = x.x.x.x
lxc.mount.auto = cgroup:rw proc:rw sys:rw

This behavior appears after the patch 50a19c6

[cyphar]

Yeah. This issue was fixed for rootless containers in #774 and IIRC @brauner (or someone on the Canonical containers team) was planning on expanding that patchset so it also works for unprivileged LXC containers. Not sure what the current status is.

Maybe I should extend it myself by doing the whole ioctl(2) magic to figure out if we're in a host user namespace?

[cyphar]

Ah sorry I think they weren't aware of this part of another patch (I must've forgotten to split this properly): d2f4969#diff-e6cd3268ea1b2c0ee41532976972b36fR433.

[anevenchanniy]

@cyphar Thanks, for your answer. I', will try to use this patch.

About user_ns detection problem, as a temporary solution,
i'm can create patch for LXC and report about using user_ns via environment variables. Like this: https://github.com/lxc/lxc/blob/master/src/lxc/start.c#L932

But of course we need specific sysctl or /proc file for this, from kernel side.

[cyphar]

Yeah, I don't think we should implement it that way. The kernel provides (in recent kernels) ioctl(2)s for nsfs file descriptors. You can use NS_GET_PARENT to figure out whether the current user namespace has a parent -- if you get EPERM then you're in a non-root user namespace.

[anevenchanniy]

@cyphar wow, cool, thanks. I'm will try this with your runc patch.

[anevenchanniy]

Folks, i'm was backported patches from @cyphar, all works fine patched docker-runc available at https://github.com/anevenchanniy/runc/tree/usern_ns patched docker-17.04 available at https://github.com/anevenchanniy/moby/tree/user_ns.

[cyphar]

@anevenchanniy In case you're interested, the patch for containerd to use runc 1.0.0-rc3 is containerd/containerd#778.

[crosbymichael]

I'll finish the docker integration tomorrow, there is a lot to do with imports, spec changes, and other deps that have changed over the past few months.

[anevenchanniy]

Tested with latest docker, issue resolved.
Thanks.