Can you expand on what use cases are not handled by setting the namespace yourself? It's not obvious to me from glancing at the issues you mention. Thanks.

I agree that creating a new socket in a different namespace is not simple, but it is also something that very few programs need to do. As long as it is possible to do this, it seems to me that this is a better fit for an external third party package than for the standard library. https://go.dev/doc/faq#x_in_std

Namespace discoverer here: it's actually much more involved, not least considering proper error handling and the multiple forms that namespace references might take on before they turn into some fd. And don't get us started on talking about the correct lifecycle handling of open fds...

I can only second @ianlancetaylor that this isn't something for the std lib, especially as it is very, very Linux-specific.

Also, why just supporting network namespaces and dial, and not the other namespace types?

I basically know of these two 3rd party libs that act as the namespace-switching building block to wrap the dial part:

• https://github.com/vishvananda/netns
• my own https://github.com/thediveo/lxkns, subpackage ops, functions Visit (or alternatively Go or Exec)

The use case is to dial or listen in another network namespace by using the standard library and hooks provided by the standard library.

Is this supported today? Sort of. You can do the following:

• Call runtime.LockOSThread
• Set the namespace of the current thread
• Invoke a dial or listen in the standard library and wait for them to return
• Revert the namespace of the current thread
• Call runtime.UnlockOSThread

You can further optimize a bit on this: You can install a Control object in the dialer/listener. As soon as it is indicated to the Control object that a socket has been created, you can go ahead and revert the namespace and call runtime.UnlockOSThread.

I see two problems with it, though:

1. It does not support the happy eyeballs algorithm when dialing
2. It kind of just happens to work due to the way the standard library happens to be implemented. For example, that the dialer and listener happen to not create new go routines.

Is this good enough? Maybe, but I do not think it is ideal.

I do agree with @thediveo that the standard library should not support Linux namespaces directly. It should provide hooks so that you can support them reliably with mechanisms like the one outlined above.

@cwmos which hooks (extension points) would you expect?

I guess I do not have any super good suggestions for how to change the API. So I will close this issue.

@cwmos Have a look at #54314 maybe.