-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Investigate whether we still need to add entries to /etc/passwd
in entrypoint.sh
#22010
Comments
Beyond the simplification, we should avoid providing R/W access to |
On clusters where Pods don't run as arbitrary users (vanilla Kubernetes?) there should be no need to inject an extra entry in |
Added to #20799 |
Issues go stale after Mark the issue as fresh with If this issue is safe to close now please do so. Moderators: Add |
/remove-lifecycle stale |
Issues go stale after Mark the issue as fresh with If this issue is safe to close now please do so. Moderators: Add |
Issues go stale after Mark the issue as fresh with If this issue is safe to close now please do so. Moderators: Add |
/remove-lifecycle stale |
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 #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 #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
The text was updated successfully, but these errors were encountered: