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 GoogleContainerTools/kaniko#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
Files being added to the workspace via
COPYandADDinstructions in the dockerfile will end up with the original permissions from the workspace mount, not the correct defaultroot:rootfile ownership.Note this is only when used with docker on Linux.
Here is a simple reproduction:
From the Dockerfile spec:
Likely caused by bug in Kaniko GoogleContainerTools/kaniko#2850
The current hacky work-around is to force the --chown:
Which seems to do the "right" thing: