Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove nsenter.c in Go >= 1.10 #1795

Closed
ccope opened this issue May 4, 2018 · 3 comments
Closed

Remove nsenter.c in Go >= 1.10 #1795

ccope opened this issue May 4, 2018 · 3 comments

Comments

@ccope
Copy link

ccope commented May 4, 2018

Go will now actually isolate an OS thread when you call LockOSThread, so the C hack shouldn't be necessary anymore: https://golang.org/doc/go1.10#runtime

@cyphar
Copy link
Member

cyphar commented Nov 24, 2018

I'm not sure that it'd be reasonable to do it, even with LockOSThread. Go will spawn threads automatically, and there's no way to stop it from doing that. CLONE_NEWUSER requires that you be a single-threaded process -- so we would have to do several hacks to get around that. Then you have the general issue that namespace operations affect only the calling thread -- and while we would execute execve(2) in the same thread we did namespace setup I am very cautious about trusting the Go runtime to not break underneath us.

To be frank, I just trust that the C code we have is doing the right thing in a way that I don't think I'll ever be able to trust the Go runtime in the same way. I've had to deal with far too many Go bugs in my time.

@ccope
Copy link
Author

ccope commented Nov 25, 2018

The change prevents spawning from locked threads, and was directly in response to the blog post about namespace issues with go: golang/go#20676

I'd consider this 'wishlist' level priority, given that the C shim seems to be doing fine, but a pure Go alternative should work if issues arise.

@brb
Copy link

brb commented Dec 21, 2018

It's unsafe to replace nsenter.c with any implementation in Go.

As @cyphar mentioned, it's not possible to ensure that all Go runtime threads will have the same thread-state modifications. Additionally, if you spawn a new goroutine from the locked one, the new goroutine will end up running on a different "non-modified" thread leading to funky results, see https://www.weave.works/blog/linux-namespaces-golang-followup.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants