Skip to content
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

Open
3 tasks
amisevsk opened this issue Feb 17, 2023 · 6 comments
Open
3 tasks
Labels
area/editor/vscode Issues related to the Code OSS editor of Che area/udi Issues and PRs related to the universal developer image https://github.com/devfile/developer-images kind/task Internal things, technical debt, and to-do tasks to be performed. severity/P1 Has a major impact to usage or development of the system.

Comments

@amisevsk
Copy link
Contributor

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

@amisevsk amisevsk added kind/task Internal things, technical debt, and to-do tasks to be performed. area/editor/vscode Issues related to the Code OSS editor of Che area/udi Issues and PRs related to the universal developer image https://github.com/devfile/developer-images labels Feb 17, 2023
@che-bot che-bot added the status/need-triage An issue that needs to be prioritized by the curator responsible for the triage. See https://github. label Feb 17, 2023
@amisevsk amisevsk added severity/P2 Has a minor but important impact to the usage or development of the system. and removed status/need-triage An issue that needs to be prioritized by the curator responsible for the triage. See https://github. labels Feb 17, 2023
@l0rd l0rd added severity/P1 Has a major impact to usage or development of the system. and removed severity/P2 Has a minor but important impact to the usage or development of the system. labels Feb 18, 2023
@l0rd
Copy link
Contributor

l0rd commented Feb 18, 2023

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
Copy link
Contributor

l0rd commented Feb 18, 2023

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
Copy link
Contributor

l0rd commented Mar 3, 2023

Added to #20799

@che-bot
Copy link
Contributor

che-bot commented Aug 30, 2023

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.

@che-bot che-bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Aug 30, 2023
@l0rd
Copy link
Contributor

l0rd commented Aug 30, 2023

/remove-lifecycle stale

@che-bot che-bot removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Aug 30, 2023
@che-bot
Copy link
Contributor

che-bot commented Feb 26, 2024

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.

@che-bot che-bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Feb 26, 2024
@che-bot che-bot closed this as completed Mar 4, 2024
@l0rd l0rd reopened this May 30, 2024
@l0rd l0rd removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label May 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/editor/vscode Issues related to the Code OSS editor of Che area/udi Issues and PRs related to the universal developer image https://github.com/devfile/developer-images kind/task Internal things, technical debt, and to-do tasks to be performed. severity/P1 Has a major impact to usage or development of the system.
Projects
None yet
Development

No branches or pull requests

3 participants