[1.1] [hotfix] nsenter: refuse to build with Go 1.22 on glibc

[kolyshkin]

This is a backport of #4234 to release-1.1 branch.

---

We will almost certainly need to eventually rework nsenter to:

1. Figure out a way to make pthread_self() not break after nsenter runs (probably not possible, because the core issue is likely that we are ignoring the rules of signal-safety(7)); or
2. Do an other re-exec of /proc/self/exe to execute the Go half of "runc init" -- after we've done the nsenter setup. This would reset all of the process state and ensure we have a clean glibc state for Go, but it would make runc slower...

For now, just block Go 1.22 builds to avoid having broken runcs floating around until we resolve the issue. It seems possible for musl to also have an issue, but it appears to work and so for now just block glibc builds.

Note that this will only block builds for anything that uses nsenter -- so users of our (internal) libcontainer libraries should be fine. Only users that are starting containers using nsenter to actually start containers will see the error (which is precisely what we want).

(cherry picked from commit e377e16)

[kolyshkin]

CI failures in cross-i386 and cirrus are expected and are being fixed in #4231 / #4239. Once either one is merged, I'll rebase.

[AkihiroSuda]

NACK for backporting, as it has been working with some glibc versions, and we can't break users' environments that have been actually functional

[liggitt]

Will this PR break things which are using go1.22 to link / build runc as a library and don't actually exercise the nsenter code at all? If so, that seems unnecessary and really problematic.

Asking another way, do we know that everything importing this package is running nsenter?

[kolyshkin]

Will this PR break things which are using go1.22 to link / build runc as a library and don't actually exercise the nsenter code at all? If so, that seems unnecessary and really problematic.

Unless nsenter is explicitly vendored, there's no breakage. You can check by doing something like go mod why github.com/opencontainers/runc/libcontainer/nsenter or git grep github.com/opencontainers/runc/libcontainer/nsenter.

Asking another way, do we know that everything importing this package is running nsenter?

I think there is some software in the wild that actually uses nsenter, but to my best knowledge kubernetes does not.

[rata]

Yeap, Kubernetes is not using nsenter.