search

appsody / stacks

Appsody application stacks. This repo will be archived soon.
https://appsody.dev
Apache License 2.0
89 stars 121 forks source link

Container home directory inconsistent on OCP vs vanilla Kube #826

Open djones6 opened 4 years ago

djones6 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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