COPY --link --chown unexpectedly changes parent dir ownership

[polarathene]

Description

Scenario: Adding content from a different image on DockerHub via COPY --link, and correcting the ownership with --chown=<uid>.

When building with the buildx driver docker-container, the parent directories (/var/lib) appear to also have had their ownership modified to the --chown value.

Reproduction

# syntax=docker.io/docker/dockerfile:1

FROM docker.io/debian:11-slim
RUN adduser --quiet --system --group --disabled-password --home /var/lib/clamav --no-create-home --uid 200 clamav
COPY --link --chown=200 --from=docker.io/clamav/clamav:latest /var/lib/clamav /var/lib/clamav

$ docker buildx create --driver docker-container --name con --use
$ docker buildx build -t test --load .
$ docker run --rm test ls -l /var | grep clamav

drwxr-xr-x 1 clamav clamav 4096 May 29 05:46 lib

We do have these current releases where you can observe this by pulling from the registry:

• mailserver/docker-mailserver:11.3.1: Dockerfile COPY --link line
• mailserver/docker-mailserver:12.0.0: Dockerfile COPY --link line with --chown=200 added

Pulling the v12 image or anything newer has /var and /var/lib with ownership of clamav / 200, when that should only apply from /var/lib/clamav as per the Dockerfile.

Additional Information

Originally we used COPY --link until realizing the UID/GID value mapping was not reliable, and that the clamav user and group could not be used with --chown with --link, so we created the user explicitly before installing a package that would create a clamav user/group, and reference that stable UID for --chown: #2987 (comment)

This bug seems related to:

• COPY command changes the directory permissions to change. #3602 (comment)
• dockerfile: eliminate dependency on dest directory for COPY #2414 (comment)

---

UPDATE: It was assumed this was only reproducing when pulling the image from DockerHub and not local builds. It can be reproduced in local builds via the buildx driver docker-container, so is possibly a buildx specific issue (unless the --load import is akin to docker pull for images using --link?)

docker version

Client: Docker Engine - Community
 Version:           24.0.1
 API version:       1.43
 Go version:        go1.20.4
 Git commit:        6802122
 Built:             Fri May 19 18:06:18 2023
 OS/Arch:           linux/amd64
 Context:           default

Server: Docker Engine - Community
 Engine:
  Version:          24.0.1
  API version:      1.43 (minimum version 1.12)
  Go version:       go1.20.4
  Git commit:       463850e
  Built:            Fri May 19 18:06:18 2023
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.6.21
  GitCommit:        3dce8eb055cbb6872793272b4f20ed16117344f8
 runc:
  Version:          1.1.7
  GitCommit:        v1.1.7-0-g860f061
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

docker info

Client: Docker Engine - Community
 Version:    24.0.1
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.10.4
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v2.18.1
    Path:     /usr/libexec/docker/cli-plugins/docker-compose

Server:
 Containers: 3
  Running: 3
  Paused: 0
  Stopped: 0
 Images: 25
 Server Version: 24.0.1
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 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 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 3dce8eb055cbb6872793272b4f20ed16117344f8
 runc version: v1.1.7-0-g860f061
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.2.0-20-generic
 Operating System: Ubuntu 23.04
 OSType: linux
 Architecture: x86_64
 CPUs: 1
 Total Memory: 945.4MiB
 Name: vpc-ubu
 ID: 028ce824-5aaf-4d0b-97cc-c31018736f0f
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

docker buildx inspect

Name:          con
Driver:        docker-container
Last Activity: 2023-05-29 05:46:03 +0000 UTC

Nodes:
Name:      con0
Endpoint:  unix:///var/run/docker.sock
Status:    running
Buildkit:  v0.11.6
Platforms: linux/amd64, linux/amd64/v2, linux/amd64/v3, linux/386

[polarathene]

For anyone that is subscribed here, I looked into this recently (the bug is still reproducible):

• --link usage modifies both permissions and ownership of the destination path parent dirs for any that already exist. I did not notice this originally as the defaults for /var/lib were already 755 0:0. --chown additionally replaces the default 0 / root fallback.
• --chmod=null as new workaround option
• Full report (docs update request)