Container home directory inconsistent on OCP vs vanilla Kube

[djones6]

Describe the bug
When running under OpenShift, the HOME directory of the user executing the application is inconsistent - at least for the couple that I was recently working with (java-spring-boot2, java-openliberty).

For example, in java-spring-boot2, the home directory is /home/java_user, unless running in OCP where it is simply /.

This is not specific or unique to Appsody stacks, but I think it something that could (should?) be handled by the stacks to give a less surprising user experience. For example, the spring stack could do something like:

# Provide consistent home directory while executing this container
ENV HOME=/home/java_user
# Make home directory accessible to the root group for running in OpenShift
RUN chgrp -R 0 /home/java_user && chmod -R g=u /home/java_user

This would mean that applications that default to searching the user's home directory for resources (such as the Postgresql connector) would search in a predictable location, and mounting volumes into that location (eg: /home/java_user/.postgresql) would work in either environment.

[neeraj-laad]

Is this purely because the user you are running with on OpenShift is different or not something you can control?

Are stacks relying on this heavily?

[scottkurz]

@djones6 you're referring to the dev container used in appsody run/debug/test or a container run from an image you built with appsody build? (Or both?)

[djones6]

@scottkurz I'm referring to a image built with appsody build, which I have then deployed to either my local k8s cluster (docker desktop) or an OpenShift cluster.

The behaviour in OpenShift is to run containers as an arbitrary userid (eg. docker run --user) rather than using the one prescribed by the image - at least, that's what it does by default. I believe the reason it does this is to prevent exploits if an insecure service was exploited in conjunction with a containerization vulnerability.

Because that userid does not exist within the image, it just gets assigned a default group of 0 (root) and default HOME of /.

Whereas in my 'vanilla' kubernetes, the container runs with whatever userid the stack Dockerfile specifies, and HOME is set to that user's associated home directory.

@neeraj-laad I'm not sure who would be reliant on this - my thought is that user applications might, most likely as a consequence of the way that other tools / connectors they use are configured. It could be that the Postgres connector is unusual in this regard but I would imagine there will be other examples.