Skip to content
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

Use docker 1.10 user namespacing #31

Merged
merged 0 commits into from
Mar 17, 2016
Merged

Use docker 1.10 user namespacing #31

merged 0 commits into from
Mar 17, 2016

Conversation

vektah
Copy link
Contributor

@vektah vektah commented Mar 17, 2016

Docker 1.10 introduces user namespacing. This allows us to lock down the docker daemon to a non root user account.

This means doing

docker run -it -v /:/hostroot busybox touch /hostroot/things-owned-by-root

Will no longer be able to modify the host as root.

Apart from being much more secure, it means that files created inside a docker based build script will be owned by buildkite-agent, instead of root. This happens often when projects volume mount the project root into the container.

This is a brand new feature, and there are likely to be bugs. At the very least wait till 1.10.3 for moby/moby#20446 to be fixed.

Things that do not work with userns:

Using --privileged mode flag on docker run

  • sharing PID or NET namespaces with the host (--pid=host or --net=host)
  • sharing a network namespace with an existing container (--net=container:other)
  • sharing an IPC namespace with an existing container (--ipc=container:other)
  • A --readonly container filesystem (this is a Linux kernel restriction against remounting with modified flags of a currently mounted filesystem when inside a user namespace)
  • external (volume or graph) drivers which are unaware/incapable of using daemon user mappings

@vektah vektah merged commit f95ffe0 into docker-1.10-userns Mar 17, 2016
@vektah vektah force-pushed the docker-1.10-userns branch from c31c95c to 945bcd2 Compare March 17, 2016 06:08
@mbj
Copy link

mbj commented Mar 17, 2016

This PR was merged with an empty diff? intentional?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants