How do I share a namespace between snap commands?

[Jamie Strandboge]

On Wed, 2016-07-27 at 15:50 +0000, David Garrod wrote:
...
> 
> The important point here is that there are multiple commands that are part of
> the snap. I start our snap using the command:
> 
> sudo /snap/bin/openswitch-appliance.start-openswitch
> 
> Inside the SNAP this creates a couple of namespaces (swns and nonet):
> 
> /sbin/ip netns add swns
> /sbin/ip netns add nonet
> 
> The problem is that if I then start up another command in the SNAP,
> specifically a bash shell using:
> 
> sudo /snap/bin/openswitch-appliance.bash
> 
> I can't get at the swns or nonet namespaces from the bash shell that gets
> started. I get errors like:
> 
> root at Snappy-Appliance:/home/netop# ip netns exec swns bash
> RTNETLINK answers: Invalid argument
> RTNETLINK answers: Invalid argument
> setting the network namespace "swns" failed: Invalid argument
> root at Snappy-Appliance:/home/netop# ip netns pids swns
> RTNETLINK answers: Invalid argument
> RTNETLINK answers: Invalid argument
> 
> Why is this? I thought all commands for my "snap" are somehow part of the same
> "snap", even though they are in different process trees. It apparently isn't
> the case. How do I get namespaces to play across these commands.
> 
I'm going to answer only part of this so everyone is on the same page and let
the snappy team comment on why this might not be working for you.

Snaps can be thought of as running inside a container, but the snappy container
differs from other containers like LXD and Docker[1] in that the application
runs (primarily) within the global namespace. We actively made this design
choice so the application is fully integrated with the rest of the system and to
facilitate arbitrary snap connections via carefully designed snappy interfaces.
For example, rather than using Linux file, IPC or pid namespaces for isolation,
we use MAC (ie, AppArmor). Snappy leverages many different techniques to provide
strong isolation though, such as seccomp syscall filtering, bind mounts, device
cgroups, private mount namespace for app-specific /tmp, and a devpts new
instance.

To the point, the design of snappy is precisely so that apps within the same
snap can work together (but also interact with other snaps in controlled ways
via interfaces).

To your specific question, I would expect one app within your snap to be able to
create a network namespace for another app in your snap to access. All of the
apps in your snap are running within the global network namespace. That said,
because of how snapd sets up bind mounts and the private mount namespace for
/tmp for each app's runtime in your snap, it sounds like there is a bug and
something might be getting in the way there (eg, a bind mount is missing, a bind
mount is hiding something from your other app, your snap needs a shared /tmp,
etc). This might explain why running all the commands from within your snap's
bash shell works when it doesn't across apps.

The snappy team can comment on this (though, perhaps filing a bug at https://bug
s.launchpad.net/snappy/+filebug with a simple reproducer would be the fastest
way to get this resolved).

> Note that currently I'm installing my SNAP --devmode and I'm also connecting
> all the network related plug/slots.
> 
This is good since we don't yet have an interface that supports setting up
network namespaces. Once your snap is working in --devmode, please file a bug
adding the snapd-interface tag. I'm not sure if this would be an extension of
network-control or a new interface-- we can discuss that at the appropriate
time.

Jamie


[1] Note, for people who want LXD and Docker, snaps are in active development
and you can expect them to work wonderfully when delivered as snaps to your
classic or all snaps systems :)
 
-- 
Jamie Strandboge             | http://www.canonical.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/snapcraft/attachments/20160727/1cd911e8/attachment.sig>