Simple network namespace handling for go.
Go to file
Martynas Pumputis b8d862b06e Add go1.10 build constraint
This prevents netns from being used on older Go runtimes on which it's
not safe to perform any state manipulations of a scheduling thread
(https://github.com/golang/go/issues/20676).

Signed-off-by: Martynas Pumputis <m@lambda.lt>
2018-12-21 10:35:45 +01:00
LICENSE Initial commit of netns package 2014-08-31 14:20:31 -07:00
README.md Add go1.10 build constraint 2018-12-21 10:35:45 +01:00
netns.go Fix typo 2016-12-19 10:16:06 -08:00
netns_linux.go Add go1.10 build constraint 2018-12-21 10:35:45 +01:00
netns_test.go Fix handling of namespaces in multi-threaded processes. 2015-01-26 16:46:24 -08:00
netns_unspecified.go Add missing stub functions to netns_unspecified.go 2016-12-19 10:15:34 -08:00

README.md

netns - network namespaces in go

The netns package provides an ultra-simple interface for handling network namespaces in go. Changing namespaces requires elevated privileges, so in most cases this code needs to be run as root.

Local Build and Test

You can use go get command:

go get github.com/vishvananda/netns

Testing (requires root):

sudo -E go test github.com/vishvananda/netns

Example

package main

import (
    "fmt"
    "net"
    "runtime"
    "github.com/vishvananda/netns"
)

func main() {
    // Lock the OS Thread so we don't accidentally switch namespaces
    runtime.LockOSThread()
    defer runtime.UnlockOSThread()

    // Save the current network namespace
    origns, _ := netns.Get()
    defer origns.Close()

    // Create a new network namespace
    newns, _ := netns.New()
    netns.Set(newns)
    defer newns.Close()

    // Do something with the network namespace
    ifaces, _ := net.Interfaces()
    fmt.Printf("Interfaces: %v\n", ifaces)

    // Switch back to the original namespace
    netns.Set(origns)
}

NOTE

The library can be safely used only with Go >= 1.10 due to golang/go#20676.

After locking a goroutine to its current OS thread with runtime.LockOSThread() and changing its network namespace, any new subsequent goroutine won't be scheduled on that thread while it's locked. Therefore, the new goroutine will run in a different namespace leading to unexpected results.

See here for more details.