Linux Namespaces and Go Don't Mix

Author of the go netlink library here. I&#x27;ve run into this issue a number of times. There has been conversation in the past about adding some kind of new runtime command like LockOSThread to prevent new threads from being spawned, but it didn&#x27;t gain any momentum.<p>Even though I am a big fan of go, I&#x27;ve personally built two container runtimes in other languages do to the namespace clumsiness.<p>Personally, I think rust is an excellent alternative for namespace utilities.<p>EDIT: there is more information and links in the issue in the netns library: <a href="https:&#x2F;&#x2F;github.com&#x2F;vishvananda&#x2F;netns&#x2F;issues&#x2F;17" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;vishvananda&#x2F;netns&#x2F;issues&#x2F;17</a>

I think the proper title is: Linux Process and Threads Don&#x27;t Mix.<p>The Linux syscall interface exposes certain functionalities that are much more easy to reason about at the process level such as namespaces, capabilities, seteuid and so on. However these syscalls all operate on the thread level (since the kernel treats threads pretty similarly to processes). Therefore in order to perform these operations safely you need some sort of process wide mechanism to apply the operation on every thread (and don&#x27;t forget error handling!)<p>This is _not_ just a golang problem or an M:N threading problem as many comments suggest. The kernel really needs to provide new syscalls for these features that operate at the process &#x2F; thread-group level. The current syscalls are extremely difficult to use correctly in any multithreaded context in any language. When you consider the security implications of these features it makes the problem even worse.<p>Check out <a href="https:&#x2F;&#x2F;ewontfix.com&#x2F;17&#x2F;" rel="nofollow">https:&#x2F;&#x2F;ewontfix.com&#x2F;17&#x2F;</a> for a really good analysis of the difficulty musl libc has faced making a multi-thread safe seteuid on Linux. There are also many bugs in glibc related to this as well. Linux makes userspace responsible for patching up the leaks in the kernel&#x27;s process abstraction and that&#x27;s really not a job that userspace is in the right position to take on.

This leads to go code being roughly as messy&#x2F;clumsy as C (or whatever else) code in the sections that need concurrency and also need to change namespace. That&#x27;s unfortunate, but I don&#x27;t know that it really &quot;raises a few eyebrows&quot;.<p>I mean, what&#x27;s the better alternative to Go for this work? Maybe Rust? It is, at least more controllable at a lower level...but, not as easy to pick up for people coming from a C&#x2F;Python&#x2F;Perl&#x2F;Ruby systems and ops background. I&#x27;m not saying one <i>should</i> use Go for containers&#x2F;namespaces programming, but a lot of people are with some success (probably also banging into the namespaces issue now and then), I&#x27;m just saying it&#x27;s not obvious to me what the better alternative would be.

this is just a more complex version of the issue where go can&#x27;t safely do the daemonize dance for a privileged port

I&#x27;ve ran into this problem before. IMO this issue has nothing to do with go and the solution is straightforward. Simply create a sub-process whenever entering a new namespace because the operation isn&#x27;t concurrency safe within a process.<p>Note that you&#x27;d run into this bug within any multithreaded process, whether the code was written in go, Java, c, or whatever.

This is discouraging considering go was initially designed as a systems programming language. I wonder if there is another way for go to handle blocking syscall such that this use case would become reliable.

I read this crap in language design and despair. This is why C is my only recourse for systems programming in *nix environments.

alternate title: developers who don&#x27;t understand user level threading don&#x27;t understand user level threading.