auth: ENOTDIR not handled when user's HOME is not a directory

[dfinkel]

Client

trace, but really the auth package.

Environment

Alpine Docker on GKE when running as the guest user which has a home directory set to /dev/null.

Code and Dependencies

Mostly irrelevant, but the code that initializes the opencensus exporter/client is:

import (
	"fmt"

	"cloud.google.com/go/compute/metadata"
	"contrib.go.opencensus.io/exporter/stackdriver"
	"go.opencensus.io/trace"
)

// SetupTracingExporter adds stackdriver to the list of exporters that will receive
// traces. defaultProjID is the GCP project ID that should be used to identify
// the Stackdriver project. defaultTraceAttributes will be appended to every
// span that is exported to Stackdriver Trace
func SetupTracingExporter(defaultProjID string, defaultTraceAttributes map[string]interface{}) (*stackdriver.Exporter, error) {
	sd, err := stackdriver.NewExporter(stackdriver.Options{
		ProjectID:              defaultedGCPProject(defaultProjID),
		DefaultTraceAttributes: defaultTraceAttributes,
	})

	if err != nil {
		return nil, fmt.Errorf("Failed to get stack driver exporter: %w", err)
	}

	trace.RegisterExporter(sd)
	return sd, nil
}

// defaultedGCPProject is a helper function to automatically get the project ID
// when running on GCE. If it's not on GCE, it will default to the default Project
// ID passed to the function
func defaultedGCPProject(defaultProjID string) string {
	if !metadata.OnGCE() {
		return defaultProjID
	}

	projectName, projErr := metadata.ProjectID()
	if projErr != nil {
		return defaultProjID
	}
	return projectName
}

Expected behavior

The trace client (or any other GCP client) initializes without any client certificate. (using the GKE/GCE metadata server oauth credentials)

Actual behavior

Setting up the opencensus stackdriver trace exporter fails with this error:

open /dev/null/.config/gcloud/certificate_config.json: not a directory

It appears that because the user's home directory (as set in /etc/passwd) is explicitly set to /dev/null, and that's not a directory, the explicit path that's constructed here fails with ENOTDIR, which doesn't match os.ErrNotExist, so it falls through and returns ENOTDIR, when this is supposed to be a default code-path. (called from here)

Additional context

We started seeing this following an upgrade to include google.golang.org/api v0.188.0

It appears that #10431 converted a benign fall-through before into a fatal error.

Notably, golang/go#18974 indicates that the Go team doesn't consider it viable to include ENOTDIR in the handling for os.ErrNotExist due to the number of ways that errno can be encountered.

I can send a PR with a fix. (interestingly, ENOTDIR and ENOENT are the only two unix errnos defined for windows (and I'm pretty sure that means all platforms)

cc: @codyoss

[dfinkel]

I've opened #10697

[quartzmo]

@dfinkel Thank you for reporting this. Reviewing your PR now.

[codyoss]

I think the correct thing here is to not check for any special errors at all. I have come across this case in the past and discussed it with the Go team. There are legacy syscall reasons why ENOTDIR is not a not exists. Instead we should treat any error as the not exist case here. This was the conclusion reached for https://go-review.git.corp.google.com/c/oauth2/+/493695 as well. Happy to accept a PR for this style of fix.

[dfinkel]

@codyoss Sure!
I'll rewrite #10697 to return errSourceUnavailable for all errors from os.ReadFile.

[dfinkel]

@codyoss I've updated #10697 to treat all non-nil errors on that that ReadFile call as unavailable. (and added a test that exercises EPERM so it's clear that that error is expected to be swallowed as well)