Docker and CoreOS: Docker crashes when using user namespaces #1728

Closed
sharenz opened this Issue Dec 23, 2016 · 3 comments

Comments

Projects
None yet
2 participants
@sharenz

sharenz commented Dec 23, 2016

Issue Report

Docker crashes when using user namespaces. The problem is, that usermod does not support -vVwW options.

More information can be found here: moby/moby#29659

Bug

CoreOS Version

CoreOS 1185.5.0 same problem also in alpha channel CoreOS alpha (1262.0.0)

$ cat /etc/os-release
NAME=CoreOS
...
BUG_REPORT_URL="https://github.com/coreos/bugs/issues"

Environment

What hardware/cloud provider/hypervisor is being used to run CoreOS?

Expected Behavior

Docker starts and uses user namespaces.

Actual Behavior

Daemon does not start.
dockerd[7233]: time="2016-12-22T13:05:07.278189571Z" level=fatal msg="Error starting daemon: Error during "dockremap" user creation: Couldn't create subordinate ID ranges: Unable to add subuid range to user: "dockremap"; output: usermod: invalid option -- 'v'\nUsage: usermod [options] LOGIN\

Reproduction Steps

touch /etc/subuid /etc/subgid
Start docker with --userns-remap option

@euank

This comment has been minimized.

Show comment
Hide comment
@euank

euank Dec 28, 2016

Member

Docker attempts to create the users/groups/files it needs by itself when --userns-remap=default is set, but does it in a way which doesn't work on container linux (namely exec-ing useradd incorrectly). That's what's causing the daemon to fail to launch.

You can manually populate the files by doing something like:

# useradd --system --shell /bin/false --no-create-home dockremap
# echo "dockremap:165536:65536" | tee /etc/subuid > /etc/subgid

The flag on the docker daemon would then have to be set to --userns-remap=dockremap so it knows not to create those users/files itself.

The daemon at least launches correctly after doing that for me.

However, when I try to actually run a container I see:

docker: Error response from daemon: oci runtime error: rootfs_linux.go:53: mounting "/dev" to rootfs "/var/lib/docker/165536.165536/overlay/18ce7cf424de06eb16713423dc069251601ef85875c737412074ae46a10ab736/merged" caused "permission denied".

I'm looking into this further to figure out exactly what's going wrong there and what's the best way to make using userns easier.

Member

euank commented Dec 28, 2016

Docker attempts to create the users/groups/files it needs by itself when --userns-remap=default is set, but does it in a way which doesn't work on container linux (namely exec-ing useradd incorrectly). That's what's causing the daemon to fail to launch.

You can manually populate the files by doing something like:

# useradd --system --shell /bin/false --no-create-home dockremap
# echo "dockremap:165536:65536" | tee /etc/subuid > /etc/subgid

The flag on the docker daemon would then have to be set to --userns-remap=dockremap so it knows not to create those users/files itself.

The daemon at least launches correctly after doing that for me.

However, when I try to actually run a container I see:

docker: Error response from daemon: oci runtime error: rootfs_linux.go:53: mounting "/dev" to rootfs "/var/lib/docker/165536.165536/overlay/18ce7cf424de06eb16713423dc069251601ef85875c737412074ae46a10ab736/merged" caused "permission denied".

I'm looking into this further to figure out exactly what's going wrong there and what's the best way to make using userns easier.

@euank euank self-assigned this Dec 28, 2016

@euank euank referenced this issue in coreos/coreos-overlay Dec 28, 2016

Closed

shadow: update for docker's userns-remap #2333

0 of 1 task complete
@euank

This comment has been minimized.

Show comment
Hide comment
@euank

euank Dec 30, 2016

Member

Update on this: I believe the above error is caused by opencontainers/runc#1215.

Member

euank commented Dec 30, 2016

Update on this: I believe the above error is caused by opencontainers/runc#1215.

@euank

This comment has been minimized.

Show comment
Hide comment
@euank

euank Jan 31, 2017

Member

This issue is fixed by the following changes:

  1. userns-remap=default auto-creating users: Fixed by coreos/coreos-overlay#2333
  2. userns-remap having mqueue errors with selinux labeling: coreos/coreos-overlay#2400
  3. Selinux labeling failing for tmpfs on 4.8+ kernels: coreos/coreos-overlay#2399

I've also written a regression test so that userns won't break again.

Thanks for reporting, the next alpha should contain all the above fixes (and the next stable should also work correctly if the subuid/subgid files are populated manually).

Member

euank commented Jan 31, 2017

This issue is fixed by the following changes:

  1. userns-remap=default auto-creating users: Fixed by coreos/coreos-overlay#2333
  2. userns-remap having mqueue errors with selinux labeling: coreos/coreos-overlay#2400
  3. Selinux labeling failing for tmpfs on 4.8+ kernels: coreos/coreos-overlay#2399

I've also written a regression test so that userns won't break again.

Thanks for reporting, the next alpha should contain all the above fixes (and the next stable should also work correctly if the subuid/subgid files are populated manually).

@euank euank closed this Jan 31, 2017

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