COPY and ADD don't add as the current user

[cyphar]

While the USER directive will change the current user, the owner of all files injected into a container using the COPY and ADD directives are always root (even if you set the user to any other user) while all other instructions will run as the specified user.

Here's an example Dockerfile:

FROM ubuntu:14.04
RUN useradd -- someuser

# Original state.
RUN whoami
RUN ls -laZ /tmp

# Add with root.
USER root
COPY somefile /tmp/copyasroot
ADD somefile /tmp/addasroot

# Add with the new user.
USER someuser
COPY somefile /tmp/copyasuser
ADD somefile /tmp/addasuser

# Will show that all files are owned by root:root.
RUN ls -laZ /tmp
RUN whoami

Is this meant to happen?

[cyphar]

Looking through the builder code (builder/builder.go), the fixPermissions function is being used to forcefully set everything to be owned by root. Is there a reason for this, @tiborvass or @erikh?

[vivekdasgupta]

As per the documentation at https://docs.docker.com/reference/builder/ the behaviour of COPY and ADD commands is as follows :

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

The USER command behaviour is as follows (as per doc):

"The USER instruction sets the user name or UID to use when running the image and for any following RUN directives."

So ideally the RUN command should use the new username, but it seems that eventually all files/directories are Chowned to root.

[cyphar]

@vivekdasgupta I understand that it is documented like that, my proposal deals entirely with the consistency of the interface. If the USER directive doesn't modify all directives (or no directives), that produces an inherent inconsistency in the interface for the USER directive (and, as a result, Dockerfiles in general). I am arguing that the design itself should be fixed, not that the implementation doesn't fit the documentation. It does fit the documentation, but the design should be revised and the new design implemented and documented.

EDIT: Whoops. Didn't realise that this was the seminal issue. My proposal for a fix is here: #7537.

[cpuguy83]

Closing as dup of #6119