CAP_NET_ADMIN not being provided with the recommended plugs

I am trying to create a snap which will create a TUN interface. I used the debug tools provided:

  • sudo snap install snappy-debug
  • sudo snap connect snappy-debug:log-observe
  • sudo /snap/bin/ scanlog

One particular message caught my eye (one time only) which was:

= AppArmor =
Time: Apr  8 12:42:29
Log: apparmor="ALLOWED" operation="capable" info="optional: no audit" error=-1 profile="snap.dovholuk.tunThing" pid=7224 comm="tunThing" capability=12  capname="net_admin"
Capability: net_admin
* adjust program to not require 'CAP_NET_ADMIN' (see 'man 7 capabilities')
* add one of 'bluetooth-control, firewall-control, netlink-audit, netlink-connector, network-control' to 'plugs'
* do nothing if using systemd utility (eg, timedatectl):
* do nothing (

I started by adding only network-control but when that didn’t work I went whole-hog and issued all the plugs listed: ‘bluetooth-control, firewall-control, netlink-audit, netlink-connector, network-control’

JUST to see if one of them worked - and which one contained the magical capability I needed… None of them seem to provide this capability. The referenced bug at is marked as resolved but it’s not exactly the same scenario as what we’re up to.

Any pointers/thoughts/tips/tricks are appreciated. Thanks for your time

For ‘tun’, network-control is definitely the one you want to use. It not only grants this capability but also gives access to /dev/net/tun.

I suggest removing all the other suggestions and leave network-control, being sure after installing your new revision that you connect the interface with sudo snap connect dovholuk:network-control. Note that unasserted installs (ie, when specifying --dangerous) will not automatically connect manually connected interfaces (and network-control is manually connected).

1 Like

Thanks for the reply! I’ve done this already as well. I also tried the snap in two different Linux variants, 16.04 Ubuntu and Linux mint 19.1. After adding the plug and manually connecting the slot as jdstrand has shown the scan log no longer reports any problems, merely Linux responds with “operation not permitted”. I filled a bug already here with some more information.

Ok, I’ve responded in the bug then. I suggest the rest of the conversation happen over there.