Most public images used in devfile registry do not work as the base for Che 7 workspaces on OpenShift

Description

OpenShift by default starts containers using a random UID for security purposes [1]. Since the UID to be used is not known at container creation time, there is no entry for the running user in /etc/passwd.

This can cause a multitude of problems:

• The terminal is buggy: tab completion does not work, pressing up arrow does not work
  • Default terminal is always /bin/sh; starting bash results in the prompt I have no name!@workspaceid $
  • User does not have a home directory, and terminal does not open to /projects
• Any program that depends on user id or home directory can have issues
  • Maven requires specifying a path to store the .m2 repo (see https://github.com/eclipse/che/issues/13451 and https://github.com/eclipse/che/pull/13453)
  • Gradle has a similar requirement
  • General errors can be hard to predict, e.g. there are some python modules that will fail similarly, and the number of tools that could fail is not something we can manage from a support perspective.
• Some configuration that relies on having a home directory is impossible, and behaviour in these cases is generally unpredictable.

The suggestions in [1] are

• Any directory that needs to be accessed must have read/write permissions for the root group. This is not a problem for directories mounted as volumes
• The /etc/passwd file should be writable by the root group. Then, an entrypoint script can execute something like

  if ! whoami &> /dev/null; then
    if [ -w /etc/passwd ]; then
      echo "${USER_NAME:-default}:x:$(id -u):0:${USER_NAME:-default} user:${HOME}:/sbin/nologin" >> /etc/passwd
    fi
  fi
  

  to set the current user correctly.

The second point above is the issue – images not created to run on OpenShift do not have a writeable /etc/passwd; further, since we normally overwrite container commands with sleep infinity or tail -f /dev/null, even images with an entrypoint that does what we need won’t execute the script by default. Note that this is what’s done when starting the default “Che 7” stack, which explains why it works.

At this time, I don’t see many good potential solutions; when running on OpenShift, the Che server could attempt to rewrite the recipe’s container commands with the script above followed by whichever non-terminating command we like, but this would still require using compatible images in the devfile registry. It could also result in confusing errors if we’re automatically rewriting entrypoints, and it’s difficult to specify a script like above in the yaml list format used for container commands.

I’m currently working with trying to implement the above, but if anyone has better ideas, it’d be great to hear them.

[1]- https://docs.okd.io/3.11/creating_images/guidelines.html#openshift-specific-guidelines

Reproduction Steps

Start a Che 7 workspace other than the default dev image (e.g. java-maven), open a terminal, and type whoami

OS and version:
Che 7 on any OpenShift

Diagnostics: In most images, we have e.g.:

$ id
uid=1075080000 gid=0(root) groups=0(root),1075080000

[ibuziuk]

@amisevsk I reworded this issue a bit to make it Che 7 specific. WDYT about closing this one and creating a separate one for the general use-case of public images as a language runtime on OpenShift? I believe we need to cross-link this new general issue with https://github.com/openshift/origin/issues/23369

[amisevsk]

@ibuziuk, speaking of split discussion: https://github.com/eclipse/che-devfile-registry/pull/38#issuecomment-513729389

I’ll open a PR to use a more convenient base image.