Group should be honoured for Docker image when overriding user.

[GrahamDumpleton]

At the current time, when running a Docker image and OpenShift overrides the user ID that the Docker container runs as, any group that the Docker image advertised via the USER statement is being ignored.

This means that if an S2I builder or other Docker image was using group membership and file system permissions as the mechanism to allow file system access for reading and updating, then the application within the container would fail when the user ID is overridden.

Imagine a Docker image that has USER specified in the Dockerfile as:

USER 1001:100

This equates to some defined user and the group 'users'.

If you were to run the Docker image and look at the identity of the image you would see:

$ docker run -it --rm -e HOME=/home/jovyan -p 8888:8888 my-minimal-notebook id
uid=1001 gid=100(users) groups=100(users)

All good it works.

In OpenShift though, we will override the user ID the container runs as. Result therefore is:

$ docker run -it --rm -u 10000 -e HOME=/home/jovyan -p 8888:8888 my-minimal-notebook id
uid=10000 gid=0(root) groups=0(root)

With the way docker run works, even though a group ID wasn't also specified with the -u option, docker run ignores itself that a group ID was part of the Docker image description. The end result is that even though not overridden the group ID is forced to 0, this being because the specified user ID has no corresponding user account in the container and so the operating system defaults to using a group ID of 0.

For an image which was set up okay to run as a non root user, and which had set up all the file system directory/file permissions such that any user in 'users' could access and write stuff, how -u works when just a user ID is passed, causes the image to fail.

It would seem more sensible that for OpenShift, where we do override the user ID, that if the Docker image description had specified a group ID, that we still honour that at least and pass it explicitly with the -u option along with our unique user ID.

Currently we tell Docker image authors that they have to ensure things can run as group ID 0 because of the above. If we honour the group when specified in USER, that provides another option if they don't want to or don't see sense in changing their existing images to use the 'root' group of 0.

Indications are that this may require upstream changes to Kubernetes as well as OpenShift. As well as the deployer, changes in the S2I builder would also be required per issue #8568.

[openshift-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.

/lifecycle stale

[GrahamDumpleton]

/lifecycle frozen

[simo5]

/assign @runcom

[php-coder]

Indications are that this may require upstream changes to Kubernetes as well as OpenShift.

Yes, it requires changes in Kubernetes. Here is the proposal: kubernetes/community#756

There is also PR that adds runAsGroup field to the SecurityContext: kubernetes/kubernetes#52077 At this time it's still in progress and isn't merged.

[runcom]

This is something we would handle in CRI-O as well

[itewk]

With the changes made in Kubernetes, is there still a change needed in OpenShift?

[runcom]

RunAsGroup is handled in kube 1.10 and CRI-O has patches being merged to support that

[seilorjunior]

This will be very nice to have