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

Make random user a real user #23369

Closed
tsmaeder opened this issue Jul 12, 2019 · 17 comments
Closed

Make random user a real user #23369

tsmaeder opened this issue Jul 12, 2019 · 17 comments
Labels
lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed.

Comments

@tsmaeder
Copy link

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.

@rhatdan
Copy link
Contributor

rhatdan commented Jul 12, 2019

CRI-O now has support for adding the entry of the user to the /etc/password if it does not exists in /etc/passwd.

@tsmaeder
Copy link
Author

@rhatdan not being super familiar with this space, how does that relate to this issue? And does it include home directory, etc. as well?

@rhatdan
Copy link
Contributor

rhatdan commented Jul 15, 2019

Yes it will generate the homedir.

+       homedir := ""
+       for _, env := range specgen.Config.Process.Env {
+               if strings.HasPrefix(env, "HOME=") {
+                       homedir = strings.TrimPrefix(env, "HOME=")
+                       break
+               }
+       }
+       if homedir == "" {
+               homedir = specgen.Config.Process.Cwd
+       }

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 "/"

@ibuziuk
Copy link

ibuziuk commented Jul 22, 2019

@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 Arbitrary User IDs support [2] on OpenShift end? Currently on Eclipse Che side in order to properly support language runtime images on OpenShift we have to do the patching explicitly [3] (on pure K8S those images work OOTB without any customizations)

[1] https://docs.openshift.com/container-platform/3.11/crio/crio_runtime.html
[2] https://docs.okd.io/3.11/creating_images/guidelines.html#openshift-specific-guidelines
[3] https://github.com/eclipse/che-devfile-registry/tree/master/arbitrary-users-patch

@rhatdan
Copy link
Contributor

rhatdan commented Jul 22, 2019

I would think CRI-O is the default contianer engine now. It is in OpenShift 4.0 so it should be here.

@ibuziuk
Copy link

ibuziuk commented Jul 22, 2019

@rhatdan cool, thanks - I believe we need to play with this a bit after our Che 7 GA release cc: @l0rd @amisevsk

@sunix
Copy link

sunix commented Jul 22, 2019

Hello @rhatdan, many thanks for the explaination!
I don't know if it is the place to report this:

On one of my containers, I have got that /etc/passwd line that has been added:

1001360000:x:1001360000:0:1001360000 user:/project:/sbin/nologin

for this container image: https://github.com/quarkusio/quarkus-images/tree/graalvm-1.0.0-rc16/centos-quarkus-maven

However, /project is not writable for the arbitrary user which doesn't make sense.

@rhatdan
Copy link
Contributor

rhatdan commented Jul 22, 2019

That must be the current working directory, if HOME is not set in the environment, that is all the tool can deal with.

@sunix
Copy link

sunix commented Jul 22, 2019

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 ?

@rhatdan
Copy link
Contributor

rhatdan commented Jul 24, 2019

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.

@sunix
Copy link

sunix commented Jul 24, 2019

Yes thanks it makes sense

@openshift-bot
Copy link
Contributor

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

@openshift-ci-robot openshift-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Oct 22, 2019
@tsmaeder
Copy link
Author

/remove-lifecycle stale

@openshift-ci-robot openshift-ci-robot removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Oct 23, 2019
@openshift-bot
Copy link
Contributor

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

@openshift-ci-robot openshift-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jan 21, 2020
@openshift-bot
Copy link
Contributor

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale

@openshift-ci-robot openshift-ci-robot added lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Feb 20, 2020
@openshift-bot
Copy link
Contributor

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

@openshift-ci-robot
Copy link

@openshift-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed.
Projects
None yet
Development

No branches or pull requests

6 participants