You and I spoke earlier this week in Seattle about your snap needs. I believe the interface plug you need is network-manager, which combined with the nmcli tool might give you the access you need. You can try it with your snap installing it locally and manually connecting it with snap connect. If that’s not correct, @niemeyer can hopefully find out what is.
I have tried connecting my snap to the :network-manager interface, but with no luck access the nmcli tool after manually connecting the interfaces to my snap. Still gives error:
bash: nmcli: command not found
when trying to run nmcli from snap run --shell [my_snap] console.
I’ve also tried this with every listed network related interface plug without any luck.
Ah I see. I’ll go ahead and bundle-in nmcli and do some testing using that method first before resorting to the dbus comm method.
You can safely bundle the nmcli binary coming from the Ubuntu archive (16.04). We currently ship the same NetworkManager version (1.2.2) as a snap which is part of 16.04.
Bundling in the nmcli does work as expected in my local development environment, but I get an AppArmor error when installing/running the snap on my Ubuntu Core device.
Error:
(process:6665): nmcli-CRITICAL **: Error: Could not create NMClient object: An AppArmor policy prevents this sender from sending this message to this recipient; type="method_call", sender=":1.36" (uid=1000 pid=6665 comm="/snap/machineshop-edge/x15/bin/nmcli c show ") interface="org.freedesktop.DBus.Properties" member="GetAll" error name="(unset)" requested_reply="0" destination=":1.7" (uid=0 pid=1578 comm="/snap/network-manager/115/usr/sbin/NetworkManager ").
Local machine:
snap 2.23.6
snapd 2.23.6
series 16
ubuntu 16.04
kernel 4.8.0-48-generic
Ubuntu Core machine:
snap 2.23.1
snapd 2.23.1
series 16
kernel 4.4.0-1003-caracalla
All of the same interfaces are connected in the same way as in my local environment. Any ideas?
The other thing I can see in your error message is that you’re calling nmcli not as root (sender=":1.36" (uid=1000 ...)). Non-root users don’t have the permissions to call everything on the service side. If you use root via sudo /snap/bin/my-app then things should work.
I do not need to expose my bundled-in nmcli to the user as a command. I need to use nmcli command from within my service. The wifi-ap snap accomplishes what I need to do, so I used it as an example.
I do have the network-manager interfaces connected to my snap’s network-manager interface, but I do see a difference in the interfaces names from my local version to my ubuntu core version:
on your classic install (desktop) the network-manager interface backend is provided through the installed network-manager deb … while ubuntu core requires you to install the network-manager snap … that is what causes the name difference (not sure but there might also be a functional difference here)
I suspect that at the time of access the security policy doesn’t contain this rule. This could be a result of nmcli running before you have manually connected the interfaces. Can you verify that the interfaces are connected with ‘snap interfaces’ and then run nmcli (and report any security policy denials).
If the interfaces show they are connected but the above rule isn’t in your policy, then that would indicate there is a bug in the interface connection code.
It’s working as expected now. The required network-manager interface was connected to my snap’s network-manager interface (see previous post), but I tried disconnecting from the network-manager:service slot then re-connecting it, and now it’s working.
On another note, is there any way to auto-connect this interface instead of having the user who installs my snap have to do so? Or are there plans for a permissions/interfaces request prompt when a user installs a snap (similar to Android) so they can be auto-connected at that time?
Hmm, if it was connected but not allowed and disconnecting/connecting fixed it, that still might indicate a bug. If you can find a reliable reproducer where snap interfaces shows it is connected but the access is still denied, please report it.
For some ‘plugs’, the base declaration deliberately makes it so these interfaces require a manual connection, usually because the interface grants privileged access to the system. https://github.com/snapcore/snapd/wiki/Interfaces gives some high-level details for each interface and whether auto-connection happens or not and why. Keep in mind, interfaces are manually connected for a reason and the user installing the snap should have a say on whether the interface should be connected. This keeps the ecosystem secure and maintains the public store’s reputation.
The snap declaration mechanism exists to override the base declaration and allow auto-connection and store reviewers may issue a snap declaration through the store. Issuing a snap declaration in this manner requires trust in the snap’s publisher because it removes the user’s choice during the install process and essentially having the brand (ie, public store or private brand store) vouch for the snap publisher. If your snap is in a brand store, then the brand owner can issue snap declarations for your brand (since vouching for your own software makes a lot of sense :).
As for prompting on install to honor the user’s input and making it easier, I believe that this is planned, though IMO we want to be careful about introducing click-through security prompts like those that plagued Android over the years (indeed, they are trying to move away from them).
I am trying to use nmcli from inside my snap (which basically is a java application).
I have successfully the nmcli binary into my snap and also made the network-manager connection.
I am still getting an error returned from nmcli con show from inside the snap. The guys on the forum have confirmed that I have no security issues so it should be all fine.
Did you also run nmcli as root as someone suggested or can you recall anything else that had to be fixed?