syscall,net: tests fail within a Podman container

[userid0x0]

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

I want to compile the latest version within podman. Debian bullseye is shipped with go 1.15 .

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="/root/.cache/go-build"
GOENV="/root/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/root/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/root/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/lib/go-1.15"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go-1.15/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/root/golang/src/go.mod"
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 -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build928199845=/tmp/go-build -gno-record-gcc-switches"

What did you do?

I tried to build Go within a Podman Container

apt install podman
cat << EOF > Dockerfile
FROM debian:bullseye-slim

ARG DEBIAN_FRONTEND=noninteractive

# see also https://podman.io/getting-started/installation#building-missing-dependencies
RUN apt update \
  && apt install -y \
    btrfs-progs \
    crun \
    git \
    golang-go \
    go-md2man \
    iptables \
    libassuan-dev \
    libbtrfs-dev \
    libc6-dev \
    libdevmapper-dev \
    libglib2.0-dev \
    libgpgme-dev \
    libgpg-error-dev \
    libprotobuf-dev \
    libprotobuf-c-dev \
    libseccomp-dev \
    libselinux1-dev \
    libsystemd-dev \
    make \
    pkg-config \
    uidmap \
  && rm -rf /var/lib/{apt,dpkg,cache,log}/

run git clone --branch go1.19.5 https://github.com/golang/go.git ~/golang
EOF
podman build --tag testme .
podman run --rm --tty --interactive testme bash -c "cd ~/golang/src; ./all.bash"

The following tests fail:

--- FAIL: TestIPConnLocalName (0.00s)
    iprawsock_test.go:98: listen ip4:icmp 127.0.0.1: socket: operation not permitted
--- FAIL: TestIPConnRemoteName (0.00s)
    iprawsock_test.go:115: dial ip:tcp 127.0.0.1->127.0.0.1: socket: operation not permitted
--- FAIL: TestIPConnSpecificMethods (0.00s)
    protoconn_test.go:174: listen ip4:icmp 127.0.0.1: socket: operation not permitted
FAIL
FAIL    net
...
--- FAIL: TestUnshareMountNameSpace (0.00s)
    exec_linux_test.go:343: unshare failed: , fork/exec /tmp/go-build1623837725/b1558/syscall.test: operation not permitted
--- FAIL: TestUnshareMountNameSpaceChroot (2.80s)
    exec_linux_test.go:394: unshare failed: , fork/exec /syscall.test: operation not permitted
--- FAIL: TestAmbientCaps (0.00s)
    exec_linux_test.go:632: fork/exec /tmp/gotest1670826556: errno 0
FAIL
FAIL    syscall

What did you expect to see?

I expect that Go detects it's running within a (podman) container and the tests succeed. Such a test might look as follows:

func isPodman() bool {
	return os.Getenv("container") == "podman"
}

Adding it to exec_linux_test.go should be straight forward:
https://github.com/golang/go/blob/master/src/syscall/exec_linux_test.go#L38
. For the other tests i am using --cap-add NET_RAW for the moment.

What did you see instead?

[bcmills]

syscall in particular should pass once CL 456375 is merged — could you try running it with that change patched in?

I would suggest filing separate issues for each of the three packages, since the fixes are presumably independent.

[bcmills]

The net failure is probably from here:
https://cs.opensource.google/go/go/+/master:src/net/platform_test.go;l=45-47;drc=627f12868c4c3e714bbb4ce4a418f918c1935dc2

The test is assuming that UID 0 implies “able to open raw IP sockets”, but that assumption does not hold in a container environment.

[bcmills]

@userid0x0, want to send a CL to fix the net tests?
https://go.dev/doc/contribute

(CC @ianlancetaylor @neild)

[userid0x0]

@bcmills I am neither a Go nor capabilities expert - I tried to setup a build job to build the latest version of podman (within a podman container). Does it make sense to check the capabilities of the current process instead of checking for UID==0?
I saw there is a capabilities module for Go.

[bcmills]

Does it make sense to check the capabilities of the current process instead of checking for UID==0?

Probably not: the POSIX extension specifying cap_get_proc was withdrawn, and cap_get_pid is a Linux-specific extension.

In general, the more robust approach is to just go ahead and make the system calls and then check the return values for error codes that look like container permission errors (EPERM, ENOSYS, ENOTSUPP, EOPNOTSUPP, perhaps EINVAL).

[userid0x0]

syscall in particular should pass once CL 456375 is merged — could you try running it with that change patched in?

I would suggest filing separate issues for each of the three packages, since the fixes are presumably independent.

I tested against 23c0121e4eb259cc1087d0f79a0803cbc71f500b (HEAD 31st January 2023) and can confirm the issues related to exec_linux_test.go are solved.

[gopherbot]

Change https://go.dev/cl/476216 mentions this issue: internal/testenv, syscall: move isNotSupported to internal/testenv

[gopherbot]

Change https://go.dev/cl/476217 mentions this issue: net: skip tests if creating a socket is disallowed