Docker Engine with Buildkit feature enabled fails to read .dockerignore symlinked from outside build context

[lawrence-law]

Description

With the Buildkit feature enabled, a docker build does not read a .dockerignore file which is symlinked from outside the build context (i.e. outside the directory with Dockerfile). The build succeeds, but files and directories specified in the .dockerignore file are included in the image.

This behaviour is not exhibited when not using Buildkit for the build. I understand this might be intended but just wanting to confirm if this is the case or if it's an unintended bug.

If this is intended, should the build fail given it seemingly can't read the contents of .dockerignore?

Steps to reproduce the issue:

1. Create the following directory structure:

configs/
  .dockerignore
product/
  .dockerignore -> ../configs/.dockerignore
  Dockerfile
  tests/

• Presume .dockerignore has one line inside it reading: tests/.

2. From within the product directory run DOCKER_BUILDKIT=1 docker build .

• You should be able to observe the resulting image has the tests directory.

3. Run docker build . without Buildkit enabled

• You should be able to observe the resulting image does not have the tests directory.

Describe the results you received:

Files and directories specified in the .dockerignore file are included in the Docker image.

Describe the results you expected:

Files and directories specified in the .dockerignore file are not included in the Docker image.

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

Output of docker version:

Client: Docker Engine - Community
 Cloud integration: 1.0.7
 Version:           20.10.2
 API version:       1.41
 Go version:        go1.13.15
 Git commit:        2291f61
 Built:             Mon Dec 28 16:12:42 2020
 OS/Arch:           darwin/amd64
 Context:           default
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.2
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.13.15
  Git commit:       8891c58
  Built:            Mon Dec 28 16:15:28 2020
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.4.3
  GitCommit:        269548fa27e0089a8b8278fc4fc781d7f65a939b
 runc:
  Version:          1.0.0-rc92
  GitCommit:        ff819c7e9184c13b7c2607fe6c30ae19403a7aff
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

Output of docker info:

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  app: Docker App (Docker Inc., v0.9.1-beta3)
  buildx: Build with BuildKit (Docker Inc., v0.5.1-docker)
  scan: Docker Scan (Docker Inc., v0.5.0)

Server:
 Containers: 2
  Running: 2
  Paused: 0
  Stopped: 0
 Images: 29
 Server Version: 20.10.2
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 269548fa27e0089a8b8278fc4fc781d7f65a939b
 runc version: ff819c7e9184c13b7c2607fe6c30ae19403a7aff
 init version: de40ad0
 Security Options:
  seccomp
   Profile: default
 Kernel Version: 4.19.121-linuxkit
 Operating System: Docker Desktop
 OSType: linux
 Architecture: x86_64
 CPUs: 8
 Total Memory: 1.943GiB
 Name: docker-desktop
 ID: VAPV:HZIV:DJNG:UYWF:IO3U:5NEW:QAD2:NR7U:IBOI:R6M2:ZDJ5:ZAPT
 Docker Root Dir: /var/lib/docker
 Debug Mode: true
  File Descriptors: 46
  Goroutines: 51
  System Time: 2021-03-03T01:53:36.282672101Z
  EventsListeners: 3
 HTTP Proxy: gateway.docker.internal:3128
 HTTPS Proxy: gateway.docker.internal:3129
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

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

[AkihiroSuda]

@tonistiigi I think this error is expected, right?

Rather, the behavior of the legacy builder seems a bug, but I'm not sure we can fix it without affecting users.

[lawrence-law]

@tonistiigi I think this error is expected, right?

Rather, the behavior of the legacy builder seems a bug, but I'm not sure we can fix it without affecting users.

Hi @tonistiigi, any chance to confirm? 🙏

[tonistiigi]

@lawrence-law Yes. Builder should never access any path outside build context that was not set in the cli arguments. All paths have checks for that, looks like .dockerignore in the old implementation is missing it based on your report. Do not rely on this and expect it to be broken in the future.

@thaJeztah Do we want to classify this as security? As .dockerignore file handling is quite specific I think it is only an information leak atm. Did some tests and it doesn't look like think this can be used to read a random file into build context but hard to be sure with all these wrappers in the old implementation. By default looks that it is a broken symlink in context.