[1.1] [hotfix] nsenter: refuse to build with Go 1.22 on glibc #4240
Conversation
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).
Signed-off-by: Aleksa Sarai <[email protected]>
(cherry picked from commit e377e16)
Signed-off-by: Kir Kolyshkin <[email protected]>
|
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? |
Unless nsenter is explicitly vendored, there's no breakage. You can check by doing something like
I think there is some software in the wild that actually uses nsenter, but to my best knowledge kubernetes does not. |
|
Yeap, Kubernetes is not using nsenter. |
5 participants
This is a backport of #4234 to release-1.1 branch.
We will almost certainly need to eventually rework nsenter to:
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)