COPY with --chown command should not require user or group IDs to exist

[robertgates55]

Actual behavior
This looks to be similar to #477, but given that was closed a year ago with unable to reproduce I thought I'd start afresh.

Building:

FROM alpine:latest AS helper
COPY --chown=1000:1000 scripts /scripts

Gives:
error building image: error building stage: failed to execute command: getting user group from chown: user: unknown user 1000

Expected behavior
This Dockerfile works with docker - I'd expect that specifying the --chown would create uid/gid 1000 without me creating them as a build step.

To Reproduce
Steps to reproduce the behavior:
Use gcr.io/kaniko-project/executor:latest (v1.2.0) to build the following image:

FROM alpine:latest AS helper
COPY --chown=1000:1000 scripts /scripts

(you'll obviously need a scripts/ dir in the build context)

[NMFR]

I stumbled on the same issue on kaniko-project/executor:v1.2.0:

error building image: error building stage: failed to execute command: getting user group from chown: user: unknown user 2000

Here is an example on how to replicate:

Dockerfile

FROM golang:1.14.2-buster@sha256:09b04534495af5148e4cc67c8ac55408307c2d7b9e6ce70f6e05f7f02e427f68 AS tools
RUN curl -sSfL https://raw.githubusercontent.com/golangci/golangci-lint/master/install.sh > /tmp/t

FROM gcr.io/distroless/base-debian10:debug@sha256:b8ec84402b588696f4c77d04cc3115b4d07ba887aaa1b1d3af0f76b2fed5f82d AS production
USER 2000:2000
WORKDIR /opt/app
COPY --from=tools /tmp/t ./t1
COPY --from=tools --chown=2000:2000 /tmp/t ./t2

Docker version 19.03.13

Run:

docker run -v $(pwd):/workspace gcr.io/kaniko-project/executor:v1.2.0 --dockerfile Dockerfile --target production --context . --no-push

My temporary workaround was removing the COPY --chown flag and modifying file permissions for all users before the copy. On my use case this is safe to do but beware of the security implications.

[franco-martin]

stumbled upon a similar issue when running in openshift. Images cant run as uid 0 so we modify all images to run as 1001. We had to replace
USER 1001
for

RUN useradd -u 1001 generic
USER 1001:1001

[tejal29]

Thanks @robertgates55. we do some processing to find if there are secondary groups for a user and probably that is where kaniko is throwing an error.

A simple patch to fix this will be see if userStr and groupStr are already int before calling out to GetUserFromUsername.
If they are, you could just return.

kaniko/pkg/util/command_util.go

Line 373 in 5f4e2f1

uidStr, gidStr, err := GetUserFromUsername(userStr, groupStr, fallbackToUID)

[abdennour]

is this fixed and how ?
indeed, i sill got same issue , and this is my dockerfile

FROM gcr.io/distroless/nodejs:14
COPY --from=build --chown=1001:0 /node /app
WORKDIR /app
USER 1001
EXPOSE 3000
CMD ["app.js"]

[abdennour]

@franco-martin , if your base image is distroless, RUN useradd will never work :(

INFO[0062] Running: [/bin/sh -c useradd -u 1001 generic]
error building image: error building stage: failed to execute command: starting command: fork/exec /bin/sh: no such file or directory

Guys, can you just it keep same behavor of docker?

[abdennour]

this is my workaround with my distroless base-image which does not have user 1001 :

FROM ... as build
.....
FROM  alpine:3.12 as usergroup
RUN addgroup -S appgroup && adduser -S appuser -u 1001 -G appgroup

#gcr.io/distroless/nodejs
FROM  gcr.io/distroless/nodejs:14
COPY --from=usergroup /etc/passwd /etc/passwd
COPY --from=usergroup /etc/group /etc/group
COPY --from=build --chown=1001:0 /node /app

Unfortunately, i had to do that.
I had to not break the compatibility between our ci env & developer env when he uses docker build in this laptop.

If you have somethingl like us (similar to packer ), i advice to prepare base image as following:

FROM alpine:3.12 as usergroup
RUN addgroup -S appgroup && adduser -S appuser -u 1001 -G appgroup

#gcr.io/distroless/nodejs
FROM  gcr.io/distroless/nodejs:14
COPY --from=usergroup /etc/passwd /etc/passwd
COPY --from=usergroup /etc/group /etc/group

Built it and tag it nexus.example.com/distroless/nodejs:14-nonroot
Now use it as base everywhere

[itscaro]

I still encountered this issue with kaniko 1.3.0

Base image: https://github.com/bitnami/bitnami-docker-zookeeper/blob/master/3/debian-10/Dockerfile#L28

Overriding Dockerfile

FROM bitnami/zookeeper

ADD --chown=1001:1001 <source url> /opt/bitnami/zookeeper/lib/

Error

 INFO[0034] ADD --chown=1001:1001 <source url> /opt/bitnami/zookeeper/lib/ 
 error building image: error building stage: failed to execute command: getting user group from chown: user: unknown user 1001

[7AC]

1.5.0 still has this issue despite #1477

[cortex93]

1.5.0 still has this issue despite #1477

Hopefully the test in #1477 did not work (a string will never be an int). Otherwise, the return statement would have returned root uid/gid instead of given values.

In addition, the expected behavior should be
If uid is parseable to an int, the int value must be kept, otherwise the uid must be lookup by name in /etc/passwd
if gid is parseable to an int, the int value must be kept, otherwise the gid must be lookup by name in /etc/group

[Kewynhe]

Hello,

I'm using 1.5.1 and I have the same issue.

Dockerfile:

Base image: https://github.com/bitnami/bitnami-docker-nginx/blob/1.19.8-debian-10-r6/1.19/debian-10/Dockerfile

# Stage 2 - the final image
FROM bitnami/nginx:1.19.7

####
SOME INSTRUCTIONS
####

COPY --chown=1001:1001 --from=node-builder /app/dist    /usr/share/nginx/html

Output:

INFO[0621] COPY --chown=1001:1001 --from=node-builder /app/dist    /usr/share/nginx/html 
error building image: error building stage: failed to execute command: getting user group from chown: user: unknown user 1001

[EarthlingDavey]

@abdennour your workaround was needed and worked when I was using a bitnami base image.

It's is not distroless, it's built on minideb. Dockerfile for reference.

Thank you ✌️

[weltonrodrigo]

Hi.

This impacts quarkus image building: quarkusio/quarkus#25499