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

Docker crashes when creating namespaces with UID in /etc/subuid and /etc/subgid #39353

Closed
daniyalj opened this issue Jun 11, 2019 · 4 comments · Fixed by #39764

Comments

@daniyalj
Copy link

@daniyalj daniyalj commented Jun 11, 2019

Description

Steps to reproduce the issue:

  1. Create subuid and subgid:

Here is what /etc/subuid and /etc/subgid look like:

$ cat /etc/subuid
610:123000:65536
$ cat /etc/subgid
610:123000:65536
  1. Create daemon.json:
# cat /etc/docker/daemon.json
{
    "icc": false,
    "live-restore": true,
    "no-new-privileges": true,
    "userland-proxy": false,
    "userns-remap": "610"
}
  1. Restart docker

Describe the results you received:

Run systemctl restart docker and docker will crash.

Run journalctl -xe to see the error:

Jun 11 12:19:22 mtldserint04.certapay.com dockerd[25538]: time="2019-06-11T12:19:22.583112066-04:00" level=info msg="User namespaces: ID ranges will be mapped to subuid/subgid ranges of: dev:dev
Jun 11 12:19:22 mtldserint04.certapay.com dockerd[25538]: Can't create ID mappings: No subuid ranges found for user "dev"

Describe the results you expected:

Docker restart doesnt crash

Additional information you deem important (e.g. issue happens only occasionally):

Here are my users

[root@mtldserint04 ~]# cat /etc/passwd | grep dev
dev:x:610:610:dev user:/home/dev:/bin/bash

Output of docker version:

docker version
Client:
 Version:           18.09.4
 API version:       1.39
 Go version:        go1.10.8
 Git commit:        d14af54266
 Built:             Wed Mar 27 18:34:51 2019
 OS/Arch:           linux/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          18.09.4
  API version:      1.39 (minimum version 1.12)
  Go version:       go1.10.8
  Git commit:       d14af54
  Built:            Wed Mar 27 18:04:46 2019
  OS/Arch:          linux/amd64
  Experimental:     false```

Output of docker info:

docker info
Containers: 24
 Running: 0
 Paused: 0
 Stopped: 24
Images: 15
Server Version: 18.09.4
Storage Driver: overlay2
 Backing Filesystem: xfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: bb71b10fd8f58240ca47fbb579b9d1028eea7c84
runc version: 2b18fe1d885ee5083ef9f0838fee39b62d653e30
init version: fec3683
Security Options:
 seccomp
  Profile: default
 userns
Kernel Version: 3.10.0-957.5.1.el7.x86_64
Operating System: Red Hat Enterprise Linux
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 7.638GiB
Name: m04.***
ID: ***
Docker Root Dir: /var/lib/docker/123000.123000
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: true
Product License: Community Engine
WARNING: bridge-nf-call-ip6tables is disabled

Additional environment details (AWS, VirtualBox, physical, etc.):

On prem RHEL 7.6 virtual machine running on VMWare

@thaJeztah

This comment has been minimized.

Copy link
Member

@thaJeztah thaJeztah commented Jun 11, 2019

@estesp

This comment has been minimized.

Copy link
Contributor

@estesp estesp commented Jun 11, 2019

Looking at the spec for the files, I do see that UID (versus username) is a valid entry in field 1. We were following the natural use of the tools from the shadow package, which always write the files with username:startID:rangeLen. I do see that the parsing routines in the shadow package source start by assuming username, but have a fallback to check for UID.

To fix this we'll have to allow for numeric ID in the parsing of /etc/sub[u,g]id files. A quick test would be to edit your files and replace 610 with dev and validate that the daemon can start properly and use the same mappings.

@daniyalj

This comment has been minimized.

Copy link
Author

@daniyalj daniyalj commented Jun 11, 2019

replacing 610 with dev username works perfectly fine

@yongtang

This comment has been minimized.

Copy link
Member

@yongtang yongtang commented Aug 18, 2019

Created a PR #39764 for the fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.