fix: revert setting default UserID and GroupID to 0:0

[johnstcn]

After looking into the failing unit tests some more, it looks like coder/kaniko@9f83bc8 actually does cause divergence from Docker behaviour.

I've included an integration test adapted from GoogleContainerTools/kaniko that reproduces the issue. It affects file permissions when changing permissions in a multi-stage build but does not appear to affect single-stage builds.

This test fails with the commit, and succeeds without. The fix has not been merged upstream yet as it would break legacy users. For now, we will revert to the upstream behaviour.

This will unfortunately re-break #70 but has a simple workaround of using COPY --chown 0:0.

[mafredri]

After looking into the failing unit tests some more, it looks like coder/kaniko@9f83bc8 actually does cause divergence from the Docker spec.

What's the divergence? As far as Docker spec is concerned, root is the default:

All files and directories copied from the build context are created with a UID and GID of 0.unless the optional --chown flag specifies a given username, groupname, or UID/GID combination to request specific ownership of the copied content.
From: https://docs.docker.com/reference/dockerfile/#copy

[johnstcn]

What's the divergence? As far as Docker spec is concerned, root is the default:

In a multi-stage build, the UIDs/GIDs of the source appear to be retained. This was the behaviour that the failing integration test was checking.

[mafredri]

I think breaking multi stage builds is a good enough reason to revert this for the time being. Let's revisit later if we can bring this in line with Docker behavior.