Please support network namespaces in an interface

[Jamie Strandboge]

Tracking bug to allow snaps to create network namespaces that can be used by the system and other snaps.

[Zygmunt Krynicki (zyga)]

This feels blocked by bidirectional mount propagation events as otherwise no matter what one snap creates no other snap can see. I would like to do this after we sort out more flexible mount namespace configuration in snap-confine.

[Zygmunt Krynicki (zyga)]

This is no longer blocked and we have a plan on how to implement it (via bidirectionally mounted directory that "ip netns" uses.

[Zygmunt Krynicki (zyga)]

Thinking about this I think we should do the same for the network namespace to what we do to the mount namespace. We could use it to let snaps "reign free" in their namespace if their want to (using raw low level tools and appropriate interfaces) or let snapd manage it (e.g. with mandatory firewall, etc). What do you think Jamie?

[Jamie Strandboge (jdstrand)]

Zygmunt, what you suggested in comment #3 is a different feature (per-snap network namespaces). This bug is about having an interface that allows a snap to manage network namespaces for the system and for other snaps to use. As such, let's keep snaps in the global network namespace and focus on letting snaps add, remove and attach to network namespaces via the 'ip netns' command (the standard tool for managing network namespaces). In that light, preliminary testing shows that using the bidirectional mount work you did for /media for /run/netns works.

As for per-snap namespaces, I'd rather not go that route until we have a clear need since it will immensely complicate network management, snap connections and general integration of snaps into the system. We'll have fine-grained network mediation in AppArmor in the fullness of time and between that feature and fixing this bug, that should cover pretty much everything we need for network mediation of snaps while still having them properly integrate into the system. If there are use cases beyond those that require per-snap network namespaces, we can investigate them when they arise and build on what we learn here.

[Jamie Strandboge (jdstrand)]

https://github.com/snapcore/snapd/pull/2450

[Jamie Strandboge (jdstrand)]

FYI, this is now supported in master via the 'network-control' interface. During PR review, Gustavo and I agreed that this didn't need to be broken out into a separate interface after all.

[Jamie Strandboge (jdstrand)]

2.20 fixes this issue as described in comment #6.