x/tools: replace use of x/sys/execabs with os/exec
Manbeardo opened this issue · comments
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}
}
Also, I guess the error message is technically incorrect if you go edge-case hunting and put ..
on your PATH for some reason?
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.
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 flaggolang.org/x/tools/go/packages
usesgolang.org/x/sys/execabs
to execute commandsgithub.com/99designs/gqlgen
depends upongolang.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
callsexecabs.Command
orexecabs.CommandContext
execabs.Command
andexecabs.CommandContext
do not respectGODEBUG=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 @golang/tools-team
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.
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?