x/tools: replace use of x/sys/execabs with os/exec

[Manbeardo]

What version of Go are you using (go version)?

$ go version
go version go1.19.4 windows/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\James\AppData\Local\go-build
set GOENV=C:\Users\James\AppData\Roaming\go\env
set GOEXE=.exe
set GOEXPERIMENT=
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\Users\James\go\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\James\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=C:\Program Files\Go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=C:\Program Files\Go\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.19.4
set GCCGO=gccgo
set GOAMD64=v1
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=C:\workspace\golang.org\x\sys\go.mod
set GOWORK=
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fno-caret-diagnostics -Qunused-arguments -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=C:\Users\James\AppData\Local\Temp\go-build2317869406=/tmp/go-build -gno-record-gcc-switches

What did you do?

I'm trying to run gqlgen (https://github.com/99designs/gqlgen) as part of a Bazel build.

What did you expect to see?

There should be some way to make gqlgen run correctly in Bazel

What did you see instead?

gqlgen fails with the error: go resolves to executable in current directory (.\external\go_sdk\bin\go.exe)

I originally commented on the execabs proposal here: #43724 (comment)

Bazel makes it intentionally difficult to ever get an absolute path in order to make builds more hermetic. To that end, Bazel runs executable files in this arrangement:

• CWD is a specially-built "execroot" directory which contains all the executable step's dependencies
• PATH is empty unless rule authors explicitly add elements to it
• rule authors are only able to add relative paths to PATH

This creates a somewhat-unusual situation where the paths to be found by exec.LookPath/execabs.LookPath aren't absolute, but they also aren't files directly in CWD. Since the paths aren't absolute, the current behavior of exec.LookPath/execabs.LookPath is to return an error. However, my understanding is that the LookPath security vulnerability is only relevant if the relative directory is conventionally listed on PATH variables in interactive sessions, but the only such conventionally-used relative path that I'm aware of is .. If it's true that . is the only relative path that regularly appears on users' PATH variables, I think it should be safe to update the enforcement check to allow relative paths outside of .:

if !filepath.IsAbs(path) && filepath.Dir(path) == '.' && godebug.Get("execerrdot") != "0" {
	return path, &Error{file, ErrDot}
}

[Manbeardo]

This is the output I'm getting from Bazel right now. Note that the path is relative, but not to a file directly in ..

[Manbeardo]

Also, I guess the error message is technically incorrect if you go edge-case hunting and put .. on your PATH for some reason?

[Manbeardo]

Also, technically I can work around this by having Bazel run a wrapper around gqlgen that converts the elements of PATH from relative to absolute paths before actually running gqlgen, but that's a really ugly solution.

[seankhliao]

Duplicate of #53962

[Manbeardo]

GODEBUG=execerrdot=0 does not solve this problem (it was set when I produced that screenshot) because:

• golang.org/x/sys/execabs does not respect that debug flag
• golang.org/x/tools/go/packages uses golang.org/x/sys/execabs to execute commands
• github.com/99designs/gqlgen depends upon golang.org/x/tools/go/packages

Further, the GODEBUG flag was created in the spirit of a temporary migration measure, but there's no reasonable way to work around this problem as a consumer of golang.org/x/tools/go/packages because:

• every successful code path in packages.Load calls execabs.Command or execabs.CommandContext
• execabs.Command and execabs.CommandContext do not respect GODEBUG=execerrdot=0 and always return an error if the executable path is not absolute

The ONLY workaround that I see here is to add a wrapper in Bazel that makes the PATH absolute, which compromises the hermeticness of the Bazel build and doesn't seem strictly necessary because Bazel's behavior can be allowed while still disallowing the use of . in PATH.

cc @ianlancetaylor

[seankhliao]

cc @golang/tools-team

[ianlancetaylor]

One way to support the Bazel use case is to make the GODEBUG=execerrdot setting permanent and to add support for GODEBUG=execerrdot to x/sys/execabs.

In general I don't think we want x/tools/go/packages to ignore exec.ErrDot errors; we explicitly decided to not do that in https://go.dev/blog/path-security.

[Manbeardo]

If the route forward is to respect the GODEBUG flag inside x/sys/execabs, should there also be a separate issue to move/copy the godebug package from a stdlib internal package to something that's usable in x/sys/execabs?