Golang stack traces swallowed when run on console with certain Linux capabilities

[tinyzimmer]

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

$ go version
go version go1.21.0 linux/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
GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/home/tinyzimmer/.cache/go-build'
GOENV='/home/tinyzimmer/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/home/tinyzimmer/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/tinyzimmer/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/lib/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/lib/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.21.0'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/home/tinyzimmer/devel/webmesh/node/go.mod'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build1187070256=/tmp/go-build -gno-record-gcc-switches'

What did you do?

I'll provide in line examples, because I am unable to reproduce on go play. Take the following simple program that panics immediately.

package main

func main() {
	panic("OH NO!")
}

Run it with go run

$ go run test.go
panic: OH NO!

goroutine 1 [running]:
main.main()
        /home/tinyzimmer/devel/webmesh/node/test.go:4 +0x25
exit status 2

Run it with a built executable with no changes

$ go build -o test test.go
$ ./test
panic: OH NO!

goroutine 1 [running]:
main.main()
        /home/tinyzimmer/devel/webmesh/node/test.go:4 +0x25

Now (on Linux) grant the binary permissions to perform net administration.

$ sudo setcap cap_net_admin=eip ./test
$ ./test
panic: OH NO!

Stack traces are gone.

What did you expect to see?

A stack trace

What did you see instead?

Nothing.

Other considerations

I have only been able to reproduce this on a console. Container images run with --cap-add or k8s pods with proper security context still produce stacktraces. strace shows a giant empty buffer being written to stderr when the problem manifests.

[ianlancetaylor]

This is because when a Go programs runs in secure mode, it acts as though GOTRACEBACK=none is set in the environment. That causes a panic to not print a stack trace. This is intended to be a security measure. See #60272.

[tinyzimmer]

I understand, and we can leave the issue closed. But what is the difference in vulnerability exposure that allows this behavior in containers? Even those using the host process namespace.

[seankhliao]

cap add and the k8s equivalent allows those permissions, but doesn't grant it to the biggest

[tinyzimmer]

But say running a docker container with --network host --ipc host --privileged?

[ianlancetaylor]

Note that a program that doesn't care about this potential vulnerability, for whatever reason, can use https://pkg.go.dev/runtime/debug#SetTraceback to get tracebacks.