Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Finding the minimal set of privileges for a docker container to spawn rootless containers #1456
I've been flailing away at the idea to run a pool of
I need to pass additional file descriptors to these children which precludes running children as siblings using the host docker daemon. So here I am and I hope I'm not overstepping my bounds by asking for guidance via an issue.
Create a root filesystem tgz:
$ docker export $(docker create alpine) > rootfs.tgz
FROM buildpack-deps RUN apt-get update && apt-get install -y --no-install-recommends \ libseccomp2 \ && rm -rf /var/lib/apt/lists/* ADD rootfs.tgz /child/rootfs ADD runc /usr/local/sbin/runc WORKDIR /child/rootfs RUN runc spec --rootless CMD ["runc", "run", "child"]
Build and run the container, adding
$ docker run --rm -it --cap-add SYS_ADMIN $(docker build -q .) container_linux.go:265: starting container process caused "process_linux.go:261: applying cgroup configuration for process caused \"mkdir /sys/fs/cgroup/cpuset/child: read-only file system\""
Same, but mount
$ docker run --rm -it --cap-add SYS_ADMIN -v /sys/fs/cgroup:/sys/fs/cgroup:rw $(do cker build -q .) container_linux.go:265: starting container process caused "process_linux.go:339: container init caused \"could not create session key: operation not permitted\""
Same, but invoke
$ docker run --rm -it --cap-add SYS_ADMIN -v /sys/fs/cgroup:/sys/fs/cgroup:rw $(do cker build -q .) runc run --no-new-keyring child container_linux.go:265: starting container process caused "process_linux.go:339: container init caused \"rootfs _linux.go:104: jailing process inside rootfs caused \\\"pivot_root operation not permitted\\\"\""
Same, but also add
$ docker run --rm -it --cap-add SYS_ADMIN -v /sys/fs/cgroup:/sys/fs/cgroup:rw $(do cker build -q .) runc run --no-new-keyring --no-pivot child / #
What kind of exposure am I creating by opening up by whitelisting the
Also, I'm past my abilities in trying to figure out how I might avoid
What kind of exposure am I creating by using the
You are already running privileged containers at this point. You'd need to do
Processes inside the container can access the host's kernel keyring directly (which contains various crypto stuff that some system components use) if a process is running with privileges. Though processes inside the inner container (if you're using user namespaces) might be blocked (I haven't read that kernel code in a while though).
In general I would discourage it, but to be honest if you don't specify
Oh sorry, this too
Rootless containers most definitely cannot do this. The reason that cgroups actually work in the inner container is because your container has
@cyphar thank you for taking the time. I'm super excited about the whole rootless container story and all the work you've been doing.
I've now been able to get a working prototype of the concept described above. The key differences are that I have been unable to get the networking setup without adding
Would it be fair to say that the machinery is not yet in place to be able to run rootless containers with networking as children of unprivileged containers themselves?
To provide network access, I've picked up @jessfraz' netns to great, frictionless effect and run this as a prestart hook. This also meant mounting the host's
Given the lack of granularity in
Please feel free to close at any time given that this isn't so much of an issue as it is a discussion. I hope that it helps someone else in their wacky experimentation down the road.
This was merely not included to prevent people from shooting themselves in the foot, it should be a privileged operation, also if people were using pivot_root they were probably using other things that were blocked as well like mount or chroot so it kinda just went hand in hand, there wasn't an exact reason
@ggoodman @cyphar Good to see the awesome discussion, I'm also trying to run runc inside a container as a normal user (rootless), where I'm facing much issues, and I do not want to run the base container will all the privileges, I was able to get it working with udocker (https://github.com/indigo-dc/udocker), but I was hoping I could use runc and avoid all the other python dependency, the problem with udocker being it does not support OCI complaint images, so I would like to get your opinions on whats the best approach and the hurdles came across while running them. Thanks.
@frezbo You can use skopeo to convert a Docker image into an OCI image (I've added support to