COPY --chown fails image build with unknown user

[chris-asl]

Actual behavior
Building a Docker image containing a COPY directive using --chown fails the build with

...
INFO[0036] COPY --chown=1001 target/quarkus-app/lib/ /deployments/lib/ 
error building image: error building stage: failed to execute command: getting user group from chown: user: unknown user 1001

I've created a repository as a minimal, complete and verifiable example which reproduces the problem I've noticed on GitLab CI, here
https://github.com/chris-asl/quarkus-dummy-project

It seems to be related with #477 and #1456, which are both closed due to no reproducibility.
@tejal29 In the provided MCVE, I can reproduce the error that's happening both on GitLab CI and my local workstation.
Please let me know if you need more information.

Expected behavior
The build of the image should succeed, copying the files inside the container layer, with the appropriate user id.

To Reproduce
Steps to reproduce the behavior:

1. git clone https://github.com/chris-asl/quarkus-dummy-project
2. cd quarkus-dummy-project
3. ./mvnw clean package

4.  docker run \
    -v "/path/to/quarkus-dummy-project":/workspace \
    gcr.io/kaniko-project/executor:v1.5.1-debug \
    --dockerfile "src/main/docker/Dockerfile.jvm" \
    --context dir:///workspace/ \
    --no-push
   

Additional Information

• Dockerfile:
  https://github.com/chris-asl/quarkus-dummy-project/blob/master/src/main/docker/Dockerfile.jvm
• Build Context
  Can be seen from the provided dummy project: https://github.com/chris-asl/quarkus-dummy-project
• Kaniko Image:
  gcr.io/kaniko-project/executor:v1.5.1-debug with the repo digest being
  gcr.io/kaniko-project/executor@sha256:e00dfdd4a44097867c8ef671e5a7f3e31d94bd09406dbdfba8a13a63fc6b8060

Triage Notes for the Maintainers

Description	Yes/No
Please check if this a new feature you are proposing
Please check if the build works in docker but not in kaniko
Please check if this error is seen when you use --cache flag
Please check if your dockerfile is a multistage dockerfile

[masini]

We have the same issue.

The problem is in the USER 1001 used inside Dockefile generated by Quarkus site.

I asked a Red Hat engineering and she said is ok because:

1. They don't want to use root
2. OpenShift randomize the user running the container, so every number is ok, but not root

Is this a bug or a wanted behaviour ?

[lenalebt]

Just in case someone else stumbles upon this and wants a workaround: The package that contains useradd is called shadow-utils for the Dcokerfile.jvm that is generated by quarkus to be able to then add the user. Took me a while to find this out.

But I'd rather want kaniko to just function the same way docker does - simply accepting that the user id does not exist and carry on...