Open amisevsk opened 1 year ago
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
.
Added to #20799
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.
/remove-lifecycle stale
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.
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 anentrypoint.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/etc/passwd
on both Kubernetes and OpenShift/bin/sh
, etc.)$SHELL
(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