Cannot run snaps apps inside a custom netns or a tmux session

snapd
1

Description

When using a snap app inside a custom network namespace or a tmux session, it fails.

I am using Kubuntu 20.04 LTS with zsh as shell. Everything is up to date.

I will use the node snap as an example:
node 12.16.3 2680 12/stable nodesource✓ classic

Normal execution

Command: node -v

Output: v12.16.3

Works as expected.

Inside netns

Command: sudo ip netns exec [MY_CUSTOM_NAMESPACE] su -c "node -v" [MY_USER]

Output: execv failed: Permission denied

Journalctl output:

may 14 20:32:50 armx-lap audit[12367]: AVC apparmor="DENIED" operation="exec" profile="/usr/lib/snapd/snap-confine" name="/usr/lib/snapd/snap-exec" pid=12367 comm="snap-confine" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0

Inside tmux session

Command: node -v

Output: execv failed: Permission denied

Journalctl output:

may 14 20:34:12 armx-lap audit[12418]: AVC apparmor="DENIED" operation="exec" profile="/usr/lib/snapd/snap-confine" name="/usr/lib/snapd/snap-exec" pid=12418 comm="snap-confine" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0

It seems that snaps are not allowed to run in those conditions.

I have the same behavior using any other snap inside a netns or a tmux session.

2

Netns is enough. This was captured on Arch:

audit: type=1400 audit(1589526837.573:402): apparmor="DENIED" 
    operation="capable" profile="/usr/lib/snapd/snap-confine" pid=21983
    comm="snap-confine" capability=4  capname="fsetid"
audit: type=1400 audit(1589526837.573:403): apparmor="DENIED" 
    operation="exec" profile="/usr/lib/snapd/snap-confine" 
    name="/usr/lib/snapd/snap-update-ns" pid=21997 comm="snap-confine"
    requested_mask="x" denied_mask="x" fsuid=0 ouid=0

cc @jdstrand

3

It seems that ip netns exec foo sh calls unshare(CLONE_NEWNS) - giving it a new mount namespace. What are we missing?

4

I cannot replicate the tmux issue. In my installation tmux was installed as a debian package, not as a snap.

5

I don’t thinks tmux is an issue. Basically everything I do in a terminal is in a tmux session and never had any issues.

6

So I know why netns is an issue.

Apparently netns is more than a network namespace, it’s really a mount namespace as well. This breaks the special arrangement done by snap-confine on the host and particularly /run/snapd/ns is no longer magic

7

The manpage sheds some light: https://manpages.ubuntu.com/manpages/trusty/man8/ip-netns.8.html

… ip netns exec automates handling of this configuration, file convention for network
namespace unaware applications, by creating a mount namespace and bind mounting all of the
per network namespace configure files into their traditional location in /etc.

It’s done to bring a per ns configuration overrides from /etc/netns/<name> for regular apps.