moby: Can't pull docker images containing device nodes when running docker inside user namespace

Description

The Docker CE daemon mostly works inside a user namespace, allowing it to be used in environments such as virtual servers implemented using LXD.

However, using most graphdrivers, it is not possible to pull any image that has device nodes, such as the ubuntu images, because a “docker: failed to register layer: Error processing tar file(exit status 1): operation not permitted.” error occurs.

Steps to reproduce the issue:

  1. Start a user namespace, eg. by starting an LXD container (giving it the security.nesting permission)
  2. Install Docker CE from the normal repository. Pull and run the hello-world program to confirm that it can run some containers.
  3. Try to pull an image containing device nodes eg. docker pull ubuntu:latest.

Describe the results you received:

A permission denied error occurs while untaring one of the image layers:

# docker pull ubuntu:latest
latest: Pulling from library/ubuntu
ae79f2514705: Extracting [==================================================>]  47.62MB/47.62MB
5ad56d5fc149: Download complete 
170e558760e8: Download complete 
395460e233f5: Download complete 
6f01dc62e444: Download complete 
failed to register layer: Error processing tar file(exit status 1): operation not permitted

Describe the results you expected:

The image should pull successfully, and the device nodes should be ignored (as they will be ignored at runtime anyway).

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

This bug was mostly fixed in 617c352, but it looks like one case was missed.

Output of docker version:

Client:
 Version:      17.09.0-ce
 API version:  1.32
 Go version:   go1.8.3
 Git commit:   afdb6d4
 Built:        Tue Sep 26 22:42:18 2017
 OS/Arch:      linux/amd64

Server:
 Version:      17.09.0-ce
 API version:  1.32 (minimum version 1.12)
 Go version:   go1.8.3
 Git commit:   afdb6d4
 Built:        Tue Sep 26 22:40:56 2017
 OS/Arch:      linux/amd64
 Experimental: false

Output of docker info:

Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 0
Server Version: 17.09.0-ce
Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: false
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 06b9cb35161009dcb7123345749fef02f7cea8e0
runc version: 3f2f8b84a77f73d38244dd690525642a72156c64
init version: 949e6fa
Security Options:
 apparmor
 seccomp
  Profile: default
Kernel Version: 4.4.0-97-generic
Operating System: Ubuntu 16.04.3 LTS
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 31.32GiB
Name: test-nwtn325
ID: PA6Z:7GWM:WVIF:JUPM:TAEM:AONA:VBOA:47JY:4OIJ:LAZZ:3533:Z7W2
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

WARNING: No swap limit support
WARNING: bridge-nf-call-iptables is disabled
WARNING: bridge-nf-call-ip6tables is disabled

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

LXD 2.0, or any other environment that uses user namespaces.

About this issue

  • Original URL
  • State: open
  • Created 7 years ago
  • Reactions: 2
  • Comments: 27 (18 by maintainers)

Most upvoted comments

@remingtonc I found the issue, I believe. I’ll pull a proper PR together to get overlay2 back in line w.r.t. running in a user namespace.

Let me see if I can get my test env. up with 18.03 and reproduce; very strange

Did some more testing; I found that overlay2 has this problem, but overlay doesn’t.