Make random user a real user

[tsmaeder]

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]

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]

@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]

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]

@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]

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

[ibuziuk]

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

[sunix]

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]

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

[sunix]

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]

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]

Yes thanks it makes sense

[openshift-bot]

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

[tsmaeder]

/remove-lifecycle stale

[openshift-bot]

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-bot]

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-bot]

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]

@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.