syscall: when the root user's group ID is not 0, TestSetuidEtc fails

[fuowang]

Go version

go version go1.23.2 linux/arm64

Output of go env in your module/workspace:

GO111MODULE=''
GOARCH='arm64'
GOBIN=''
GOCACHE='/root/.cache/go-build'
GOENV='/root/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='arm64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/root/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/root/go'
GOPRIVATE=''
GOPROXY='https://goproxy.cn,direct'
GOROOT='/usr/lib/golang'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN=''
GOTOOLDIR='/usr/lib/golang/pkg/tool/linux_arm64'
GOVCS=''
GOVERSION='go1.23.2'
GCCGO='gccgo'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/usr/lib/golang/src/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 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build3558252436=/tmp/go-build -gno-record-gcc-switches'

What did you do?

The test case is not robust. When the root user belongs to a special user group (for example, in a mock environment), TestSetuidEtc will fail.

1.1. In the root user environment, check the current user group ID: id
1.2. Execute the test command: cd /usr/lib/golang/src/syscall && go test -run TestSetuidEtc
1.3. The test passes.

2.1. Create a new test user group named test: groupadd test
2.2. Use the newgrp command to set the root's effective user group to test: newgrp test
2.3. Check the current user group ID: id
2.4. Execute the test command again: cd /usr/lib/golang/src/syscall && go test -run TestSetuidEtc
2.5. The test fails.

What did you see happen?

The test fails.

--- FAIL: TestSetuidEtc (0.01s)
    syscall_linux_test.go:571: [0] "Setegid(1)" comparison: "/proc/3155/status" got:"Gid:\t1001\t1\t1001\t1" want:"Gid:\t0\t1\t0\t1" (bad) [pid=3155 file:'Name:        syscall.test
        Umask:  0022
        State:  R (running)
        Tgid:   3155
        Ngid:   0
        Pid:    3155
        PPid:   3068
        TracerPid:      0
        Uid:    0       0       0       0
        Gid:    1001    1       1001    1

What did you expect to see?

We can add a check: if syscall.Getgid() != 0, then skip the current test.

[gabyhelp]

Related Issues and Documentation

• syscall: TestGroupCleanup failed #16224 (closed)
• syscall: TestSetuidEtc failure #54273 (closed)
• syscall.TestSetuidEtc() fails in some container setups #46145 (closed)
• syscall: TestSetuidEtc failures on linux-ppc64-buildlet #42462 (closed)
• "syscall.Getuid()" returns "0" when run with "sudo" #25718 (closed)
• syscall: TestGroupCleanupUserNamespace needs additional output value #16303 (closed)
• syscall: TestGroupCleanupUserNamespace test failure on CentOS #34547 (closed)
• syscall: TestGroupCleanupUserNamespace test failure on Fedora #46752 (closed)
• syscall: supplementary groups are not cleared #15865 (closed)
• syscall: TestGroupCleanupUserNamespace failure on linux-s390x-ibm #52088 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[gopherbot]

Change https://go.dev/cl/620775 mentions this issue: syscall: skipping TestSetuidEtc when root's gid is not 0