che
che copied to clipboard
eclipse-che
Investigate whether we still need to add entries to `/etc/passwd` in entrypoint.sh
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 https://github.com/eclipse/che/issues/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/passwdon 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
- Note in Che Code, the shell used for terminals in the editor can be overridden by setting
- [ ] Development tools continue to work without issue (e.g. previously we ran into issues with maven, gradle, python, etc.)
(See https://github.com/eclipse/che/issues/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: https://github.com/eclipse/che/issues/13454
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.
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.
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.
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.
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.
