Consider exposing credentials via an environment variable that isn't $HOME

[dprotaso]

In the creds-init docs under the section Exposing the credential integration it says

To solve this, prior to even the Source step, we will run a credential initialization process that accesses each of its secrets and aggregates them into their respective files in $HOME.

Expected Behaviour

The $HOME env var exposed matches the pathname of the user's home directory. As per the POSIX definition.

Actual Behaviour

Certain applications fetch the user's home directory using the syscalls getpw*. This returns a different directory than the$HOME env var that's set by the build controller for each step.

Steps to Reproduce the Problem

Write a go program and use the os/user package to print the current user's home dir using HomeDir.

Make sure the program is compiled with cgo enabled. Enabling cgo uses the getpwuid_r

Potential Solutions

• Update the entry in/etc/passwd have have pw_dir match the cred-init path
• Change the cred-init $HOME to match what's in the /etc/passwd
• (preferred) Use a different env var to refer to the location of the cred-init output

[dgodd]

This issue affected me today. It turns out that maven uses (one of the many mechanisms to) determine the home directory from the users specified home directory rather than using $HOME. Thus whilst creating files in $HOME (specifically $HOME/.m2) they were not being reflected in maven.

I would like $HOME to not be changed by knative. However I also need the docker config.json which knative places in /builder/home, and I realise determining where else this should go by reading the image is non trivial

[dprotaso]

This explains the need for this workaround https://github.com/knative/build/blob/95e3199746a50f0a4e4ba62f1d8760e9a203b30e/cmd/git-init/main.go#L59-L67

[nader-ziada]

/assign @shashwathi

[dprotaso]

Moving some of the discussion form #373 to here:

Some context from @ImJasonH: https://github.com/knative/build/pull/373#issuecomment-424092807

Another benefit of having a persistent $HOME dir is to support tools that write config to $HOME, e.g., git config user.name or gcloud config set project. We got a fair number of confused users in GCB before we persisted $HOME across steps, since they would set some config in step 0 and it would be gone by step 1.

I don't think the Build CRD can reliably assume and specify a $HOME directory due to the infinite variability of the images being used in a build's steps. For example an image can change the running user or even change the user home directory in /etc/passwd. Because of this programs that don't read the $HOME env var break and require work arounds. For now we know this affects apps built with go & java since their stdlib uses a syscall which reads /etc/passwd

Using a different env var ie. $BUILDER_HOME would require steps to parse the file contents of the directory. I'm wondering a better approach would be to hint available credentials & configs with more specified env vars ie.

• BUILDER_SSH_CONFIG specifies the location of ssh credentials provided by creds-init
• BUILDER_DOCKER_CONFIG specifies the location of a docker config file provided by creds-init
• etc...

It would be each step's responsibility stage these appropriate locations (since it will vary depending on the image).

In regards to users wanting a persistent $HOME maybe this becomes their own responsibility to manage. It could be accomplished through the use if an emptyDir volume that's specified in their Build spec.

[dprotaso]

/cc @nebhale who's been working on the java-buildpack to provide his experience with the BuildCRD