-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Make random user a real user #23369
Comments
CRI-O now has support for adding the entry of the user to the /etc/password if it does not exists in /etc/passwd. |
@rhatdan not being super familiar with this space, how does that relate to this issue? And does it include home directory, etc. as well? |
Yes it will generate the homedir.
Basically this checks if HOME is set in the environment, if so then it sets this as homedir, else it will set the homedir to the Current Working Directory, which I believe defaults to "/" |
@rhatdan any plans to enable CRI-O [1] as a default container engine? Otherwise, would it be possible to prioritize an option that would do all the tricks related to [1] https://docs.openshift.com/container-platform/3.11/crio/crio_runtime.html |
I would think CRI-O is the default contianer engine now. It is in OpenShift 4.0 so it should be here. |
Hello @rhatdan, many thanks for the explaination! On one of my containers, I have got that
for this container image: https://github.com/quarkusio/quarkus-images/tree/graalvm-1.0.0-rc16/centos-quarkus-maven However, |
That must be the current working directory, if HOME is not set in the environment, that is all the tool can deal with. |
Yes this is the current directory. Arbitrary user doesn't have permission on it. But even if HOME were set, the arbitrary user wouldn't have write access permission on it, right ? |
It would be up to the container image. For example /tmp or /var/tmp would probably be writeable by the user, or if the volume was mounted into the container, which is what something like OpenShift does. But it is also the case that in a alot of situations the user process inside of a container does not need to write to it's home directory, so this is not an issue. The main reason for having the entry inside of the /etc/passwd file at all is so that getpwbyuid() calls in libc does not fail. |
Yes thanks it makes sense |
Issues go stale after 90d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle stale |
/remove-lifecycle stale |
Issues go stale after 90d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle stale |
Stale issues rot after 30d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle rotten |
Rotten issues close after 30d of inactivity. Reopen the issue by commenting /close |
@openshift-bot: Closing this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
I'm aware that OpenShift runs containers as an arbitrary user (not root). That's fine by me. However, a lot of docker images out there have a problem when running as a user that is not "complete" in that it does not have a home directory, password, etc.
My suggestion would be that the workarounds described here be somehow done by OpenShift itself.
The text was updated successfully, but these errors were encountered: