New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow engine to run inside a user namespace #25672

Merged
merged 2 commits into from Aug 16, 2016

Conversation

Projects
None yet
8 participants
@estesp
Contributor

estesp commented Aug 12, 2016

Carry of PR #20902

Allow the Docker daemon to run inside a user namespaced parent process. Original patch by @hallyn; I've added a change to revert to "real" chroot when inside a userns that came about since the original patch.

I have tested this capability inside lxc running an ubuntu:xenial image with a binary built from this PR patchset. To successfully run the Docker daemon I used the following command line:

dockerd -D -s vfs --oom-score-adjust=0

Inside a user namespace, writing to the oom_score_adj special proc file fails, and I can't get any backend driver to work outside of vfs.

I cannot run the Docker engine inside of a runc container with user namespaces enabled due to how the /sys/fs/cgroups mount is handled under runc. Therefore it is hard to write a test that integrates well with our CI system without requiring a working LXC setup until we solve this problem in runc.

hallyn and others added some commits Feb 13, 2016

Don't create devices if in a user namespace
If we are running in a user namespace, don't try to mknod as
it won't be allowed.  libcontainer will bind-mount the host's
devices over files in the container anyway, so it's not needed.

The chrootarchive package does a chroot (without mounting /proc) before
its work, so we cannot check /proc/self/uid_map when we need to.  So
compute it in advance and pass it along with the tar options.

Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Use real chroot if daemon is running in a user namespace
The namespace unshare+pivot root is not possible when running inside a
user namespace, so fallback to the original "real" chroot code.

Docker-DCO-1.1-Signed-off-by: Phil Estes <estesp@linux.vnet.ibm.com>
@justincormack

This comment has been minimized.

Show comment
Hide comment
@justincormack

justincormack Aug 13, 2016

Contributor

LGTM but I think we should document the cant-create-devices restriction somewhere (probably dont need to mention the chroot) as it is not something people would necessarily realise. Plus the --oom-score-adjust=0 and other restrictions. Not sure where, maybe in the security docs?

Contributor

justincormack commented Aug 13, 2016

LGTM but I think we should document the cant-create-devices restriction somewhere (probably dont need to mention the chroot) as it is not something people would necessarily realise. Plus the --oom-score-adjust=0 and other restrictions. Not sure where, maybe in the security docs?

@kimh

This comment has been minimized.

Show comment
Hide comment
@kimh

kimh Aug 14, 2016

@estesp Thanks for the PR.

I used lxd and launched a container with lxc launch ubuntu-daily:16.04 docker -p default -p docker and I can run docker inside the container.

kimh commented Aug 14, 2016

@estesp Thanks for the PR.

I used lxd and launched a container with lxc launch ubuntu-daily:16.04 docker -p default -p docker and I can run docker inside the container.

@estesp

This comment has been minimized.

Show comment
Hide comment
@estesp

estesp Aug 15, 2016

Contributor

@justincormack agree on the docs need..but where? Is that the same section as user namespaces support in the daemon, or some other place that talks about environment in which you run the daemon? Seems like it should be the latter, but that points to less clear locations as there are lots of various bits about running/configuring the engine.. any guidance appreciated! /cc @thaJeztah

Contributor

estesp commented Aug 15, 2016

@justincormack agree on the docs need..but where? Is that the same section as user namespaces support in the daemon, or some other place that talks about environment in which you run the daemon? Seems like it should be the latter, but that points to less clear locations as there are lots of various bits about running/configuring the engine.. any guidance appreciated! /cc @thaJeztah

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Aug 15, 2016

Member

I think we could think of moving user namespaces to a separate document, instead of cramming it all in the dockerd reference; that way we can provide a bit more context, tips/tricks and explain when it's useful (and when not).

ping @sfsmithcha wdyt?

Member

thaJeztah commented Aug 15, 2016

I think we could think of moving user namespaces to a separate document, instead of cramming it all in the dockerd reference; that way we can provide a bit more context, tips/tricks and explain when it's useful (and when not).

ping @sfsmithcha wdyt?

@justincormack

This comment has been minimized.

Show comment
Hide comment
@justincormack

justincormack Aug 15, 2016

Contributor

@thaJeztah but this is about running docker inside a user namespace, really goes in the how to install/run docker section.

Contributor

justincormack commented Aug 15, 2016

@thaJeztah but this is about running docker inside a user namespace, really goes in the how to install/run docker section.

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Aug 15, 2016

Member

@justincormack oh, darn, was too quick answering. erm, yes, good question not sure where to put that; it's not a regular install, same as we don't document "docker in docker"

Member

thaJeztah commented Aug 15, 2016

@justincormack oh, darn, was too quick answering. erm, yes, good question not sure where to put that; it's not a regular install, same as we don't document "docker in docker"

@justincormack

This comment has been minimized.

Show comment
Hide comment
@justincormack

justincormack Aug 15, 2016

Contributor

Yes, lets maybe leave the docs for now...

LGTM

Contributor

justincormack commented Aug 15, 2016

Yes, lets maybe leave the docs for now...

LGTM

@vdemeester

This comment has been minimized.

Show comment
Hide comment
@vdemeester
Member

vdemeester commented Aug 16, 2016

LGTM 🐱
/cc @crosbymichael @cpuguy83

@thaJeztah thaJeztah added this to the 1.13.0 milestone Aug 16, 2016

@crosbymichael

This comment has been minimized.

Show comment
Hide comment
@crosbymichael

crosbymichael Aug 16, 2016

Contributor

LGTM

Contributor

crosbymichael commented Aug 16, 2016

LGTM

@crosbymichael crosbymichael merged commit 6e08c4b into moby:master Aug 16, 2016

8 checks passed

docker/dco-signed All commits signed
Details
documentation success
Details
experimental Jenkins build Docker-PRs-experimental 22386 has succeeded
Details
gccgo Jenkins build Docker-PRs-gccgo 8962 has succeeded
Details
janky Jenkins build Docker-PRs 31027 has succeeded
Details
userns Jenkins build Docker-PRs-userns 13052 has succeeded
Details
win2lin Jenkins build Docker-PRs-Win2Lin 29680 has succeeded
Details
windowsRS1 Jenkins build Docker-PRs-WoW-RS1 1748 has succeeded
Details

@estesp estesp deleted the estesp:run-docker-in-userns branch Jan 24, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment