Cannot start function container when container user does not exist within crossplane-xfn container

Inizia riproducendo il malfunzionamento con il Dockerfile e labelizer.sh mostrati nell’issue, usando un’immagine function il cui utente configurato non è presente in /etc/passwd. Poi traccia l’entry point Go che invoca il container OCI e risolve il relativo utente. Il lavoro è completato quando i container function si avviano correttamente anche se il loro utente configurato non è presente nell’immagine crossplane-xfn, inclusi UID arbitrariamente elevati o casuali.

What happened?

Working on https://github.com/crossplane/crossplane/pull/4261 required creating a custom, but simple function image that labels all managed resources with a given label. My first idea was to use yq for that and the initial Dockerfile was just:

FROM mikefarah/yq:4.34.1

COPY labelizer.sh /bin

ENTRYPOINT ["/bin/labelizer.sh"]

with /bin/labelizer.sh being just:

#!/usr/bin/env sh

yq '(.desired.resources[] | .resource.metadata.labels) |= {"labelizer.xfn.crossplane.io/processed": "true"} + .'

Unfortunately, adding this function to a composition resulted with the following error in crossplane-xfn logs:

cannot compose resources: cannot run Composition Function pipeline: cannot run function "labelizer":
cannot run container: rpc error: code = Unknown desc = exit status 1: xfn: error: spark.Command.Run(): 
cannot create OCI runtime bundle: cannot write OCI runtime spec: cannot create new spec: 
cannot apply spec option: cannot resolve user specified by OCI image config: 
cannot resolve UID of user "yq" that doesn't exist in container's /etc/passwd

Modifying the image to use root to run the script resolved the issue.

How can we reproduce it?

• deploy crossplane with enabled composition functions
• build and publish the function image using files stated above
• create a composition referring that function

What environment did it happen in?

The issue is spotted on the latest master, but I am pretty sure that versions containing composition function feature suffer from the same issue.

Expectations

Function containers should be successfully invoked independently if container user exists within crossplane-xfn container/image. We should even encourage function authors to use some arbitrary high/random UID for function.