bad handling of config files in /dev/null HOME

[codyoss]

We need to fixup the handling of opening files that don't exist. Not enough cases are handled. I am working around this in the Go auth library in https://github.com/googleapis/google-cloud-go/pull/11013.

The following issues are related:

• https://github.com/googleapis/google-cloud-go/issues/10946
• https://github.com/googleapis/google-cloud-go/issues/10844
• https://github.com/googleapis/google-cloud-go/issues/10696

The similar failure case here is HOME being set to /dev/null. If you try to open a file here you get ENOTDIR which is not a os.ErrNotExists, on purpose. The fix is remove this conditional and assume ErrConfigUnavailable here: https://github.com/googleapis/enterprise-certificate-proxy/blob/cfd7e8b9dd217c52614917367157a5e5eab34e76/client/util/util.go#L48-L51. There may be more instance of this in the codebase, but this is what I noticed.

[codyoss]

cc @andyrzhao

[andyrzhao]

Thanks for putting in a short-term workaround in the Golang GUAC library Cody! However, I'd like to know more about why HOME is being set to /dev/null. It almost feels like we SHOULD treat this scenario as a misconfiguration and fail it on the client side, similar to other bad configuration paths that would result in ENOTDIR. However, if you believe HOME = /dev/null is a legitimate default in certain environments, then maybe the right place to patch it is in the guessHomeDir section and reject ENOTDIR values of HOME. WDYT?