Please enable kernel-module-control for domotzpro-agent-publicstore snap


Recently we introduced the ability of setting up VPN connections using our package.
To perform this kind of task we need to load the kernel module “tun”.

Since we haven’t got the kernel-module-control interface, we are not allowed to perform
modprobe tun” and it is preventing the VPN setup for those environments the “tun” module is not loaded yet.

Could you please allow our snap to use the kernel-module-control interface?


according to

(in: 2. Configuration/Driver module autoloading)

the kernel should auto-load the module when you create the tun interface. you can create tun interfaces using the network-control interface … i dont think the store policy allows the usage of kernel-module-control in non-brand-store snaps …

Thanks for you prompt response.

My target system is a Raspbian GNU/Linux 10 (buster) and I’m trying the following command
without any snap confinement:

sudo ip tuntap add tap0 mode tap

I can confirm the tun module is loaded automatically.


if I try the same command within the snap domotzpro-agent-publicstore, I receive several error messages related to permissions, even if the network-control interface is connected.
That’s why we were requiring kernel-module-control as well.

After further testing it seems the issue is not present on the ubuntu-18.04 amd64 distribution.


Can you paste the permissions errors you are seeing?

Here you are with the error messages:

pi@raspberrypi:/home/pi$ sudo ip tuntap add tap0 mode tap
sudo: unable to set runas group vector: Operation not permitted
sudo: unable to set runas group vector: Operation not permitted
sudo: no tty present and no askpass program specified
sudo: unable to open audit system: Operation not permitted
sudo: unable to open audit system: Operation not permitted

well, that seems to be sudo itself not being able to operate (all these messages are sudo errors) ?

i.e. from man sudo:

     -P, --preserve-groups
                 Preserve the invoking user's group vector unaltered.  By default, the sudoers policy will initialize the group vector to the list of
                 groups the target user is a member of.  The real and effective group IDs, however, are still set to match the target user.

Please note that if using sudo, a) it needs to be properly configured and invoked for the calling user and b) the snap itself can’t use sudo. Once you’ve sorted that out, if there are other permissions issues, please post both program output and journalctl output at the time of the error.

Ok, I see your point.
The permission issue I’m experiencing is related to sudo rather than the tun interface.
Said that, I’m now wondering if forcing sudo within the snap is actually a deprecated mothod and I’ve to get the same achievement other way.


this should have never worked at all since sudo inside the snap can not actually see the host configuration it would need under proper confinement …

that said … if you run on a distro with degraded confinement due to missing kernel security features like raspbian, you might be able to accidentially have this access …