workspace file permissions incorrect from COPY instruction

[coryb]

Files being added to the workspace via COPY and ADD instructions in the dockerfile will end up with the original permissions from the workspace mount, not the correct default root:root file ownership.

Note this is only when used with docker on Linux.

Here is a simple reproduction:

$ cat .devcontainer/devcontainer.json
{"build":{"dockerfile":"Dockerfile"}}

$ cat .devcontainer/Dockerfile
FROM ubuntu
COPY files /files
RUN find /files -ls

$ docker run --rm -e WORKSPACE_FOLDER=/workspace -e INIT_SCRIPT=/bin/true -v $(pwd):/workspace ghcr.io/coder/envbuilder
...
#2: Running: [/bin/sh -c find /files -ls]
 18395960      4 drwxr-xr-x   2 1000     1000         4096 Dec 17 01:18 /files
 18395961      0 -rw-r--r--   1 1000     1000            0 Dec 17 01:17 /files/some.txt

From the Dockerfile spec:

All new files and directories are created with a UID and GID of 0.

Likely caused by bug in Kaniko https://github.com/GoogleContainerTools/kaniko/issues/2850

The current hacky work-around is to force the --chown:

COPY --chown=0:0 files /files

Which seems to do the "right" thing:

#2: Running: [/bin/sh -c find /files -ls]
 18395960      4 drwxr-xr-x   2 root     root         4096 Dec 17 01:23 /files
 18395961      0 -rw-r--r--   1 root     root            0 Dec 17 01:23 /files/some.txt

[coryb]

Looks like a PR was created 7mo ago in Kaniko, but it is still unmerged https://github.com/GoogleContainerTools/kaniko/pull/2494

Maybe we can cherry pick this commit into the coder/kaniko fork?

[johnstcn]

Unfortunately, it looks like the upstream fix breaks user/group ownership in multi-stage builds.