Investigate whether we still need to add entries to /etc/passwd in entrypoint.sh

[amisevsk]

Is your task related to a problem? Please describe

Clusters using CRI-O support automatically adding an entry to /etc/passwd on launch. Currently, containers used in Che generally use an entrypoint.sh that sets up a similar entry (see pre-CRI-O issue #13454) in order to set up login shell, home directory, and user name.

If this functionality is no longer required, removing it could simplify the requirements Che has for developer containers.

Describe the solution you'd like

Investigate if we can safely remove the /etc/passwd editing steps from entrypoints used in Che. To verify this does not cause issues, it is necessary to verify that

• Entries get added on all standard installations of Che -- i.e. we can expect the cluster to inject an appropriate entry into /etc/passwd on both Kubernetes and OpenShift
• The terminal behaves as expected (tab completion, home directory, shell is not /bin/sh, etc.)
  • Note in Che Code, the shell used for terminals in the editor can be overridden by setting $SHELL
• Development tools continue to work without issue (e.g. previously we ran into issues with maven, gradle, python, etc.)

(See #13454 for the original problems solved by setting up /etc/passwd as we do currently)

Describe alternatives you've considered

It's probably safer to keep our known-good solution here rather than simplifying entrypoints and potentially introducing unexpected bugs. We have in the past seen a wide variety of unexpected failures if the user for the pod is not set up correctly.

Additional context

Relevant older issue: #13454

[l0rd]

If this functionality is no longer required, removing it could simplify the requirements Che has for developer containers.

Beyond the simplification, we should avoid providing R/W access to /etc/passwd because this is considered not secure and highly discouraged. I am setting https://github.com/eclipse/che/labels/severity%2FP1.

[l0rd]

we can expect the cluster to inject an appropriate entry into /etc/passwd on both Kubernetes and OpenShift

On clusters where Pods don't run as arbitrary users (vanilla Kubernetes?) there should be no need to inject an extra entry in /etc/passwd.

[l0rd]

Added to #20799

[che-bot]

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.

[l0rd]

/remove-lifecycle stale

[che-bot]

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.