Description
What version of Go are you using (go version)?
$ go version go version devel +926994fd7c Thu Nov 26 21:10:09 2020 +0000 darwin/amd64
Does this issue reproduce with the latest release?
No, it's only reproducible in TIP
What operating system and processor architecture are you using (go env)?
go env Output
$ go env GO111MODULE="" GOARCH="amd64" GOBIN="" GOCACHE="/Users/christopherwaldon/Library/Caches/go-build" GOENV="/Users/christopherwaldon/Library/Application Support/go/env" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="darwin" GOINSECURE="" GOMODCACHE="/Users/christopherwaldon/Code/go/pkg/mod" GONOPROXY="" GONOSUMDB="" GOOS="darwin" GOPATH="/Users/christopherwaldon/Code/go" GOPRIVATE="" GOPROXY="https://proxy.golang.org,direct" GOROOT="/Users/christopherwaldon/Code/builds/go" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/Users/christopherwaldon/Code/builds/go/pkg/tool/darwin_amd64" GOVCS="" GOVERSION="devel +926994fd7c Thu Nov 26 21:10:09 2020 +0000" GCCGO="gccgo" AR="ar" CC="clang" CXX="clang++" CGO_ENABLED="1" GOMOD="/dev/null" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/1y/0b2jj2p97bn5003_cxtrxrg40000gn/T/go-build007027862=/tmp/go-build -gno-record-gcc-switches -fno-common"
What did you do?
An application that I maintain targets iOS, and I compiled it using the master branch of Go in order to get around the CFLAGS breakage that won't be fixed until the Go 1.15.6 release. It always crashed at startup when build with the master branch, and I saw this in the log:
Nov 29 16:24:06 kernel(Sandbox)[0] <Error>: Sandbox: Sprig(481) deny(1) file-write-create /private/var/mobile/Containers/Data/Application/0A1A0815-9F18-49E3-89C3-F99B6EFE1C9A/.config
The fact that this wasn't broken before, and that it ends with the incorrect path for the configuration directory led to to investigate where this path was coming from. It's emitted by os.UserConfigDir. After some digging, I realized that the logic in this and related OS functions do not handle the new runtime.GOOS value of ios.
To reproduce, build any code targeting iOS and invoke those functions. You'll fall through to the XDG case instead of the expected GOOS=darwin, GOARCH=arm64 ones.
I believe this was introduced by the changes here.
What did you expect to see?
I expected to be returned the correct config directory path.
What did you see instead?
I got the XDG-style config path instead, which the iOS sandbox prohibits writing to.
I already have a fix for this, and I'll open a PR right after this issue to propose the tweak to fix it. It's really straightforward, I think.