We would like to have these two additional interfaces auto-connected when the network-manager snap is installed:
The first one lets NetworkManager know when I user logs into/out of the system (UserNew signal and so on). NM connections can be configured so they are activated when, for instance, a user logs in.
The second is to allow some of the hooks we have to run the ‘ip’ command - we could just include it in the snap, but using the one in the core snap saves quite a bit of space. Note that this interface is not really granting permissions for anything additional to what the snap is already allowed to do.
Can you expand on this? Does it imply that we have interfaces that need a refactor? I figured the interfaces would be controlling underlying behavior, not just allowing or not allowing for particular binaries in the core snap to be called which could be worked around by simply bundling said binary.
Well, in the case of network-observe, it is controlling underlying behavior plus giving access to tools that are in the core snap to access easily to that behavior. But, NM already has access to the network-manager interface that has adequate networking permissions, so we only need the tool here. It would be possible to grant access to the ip command from the network-manager interface too. Or maybe split access to tools and permissions in different interfaces. But refactoring interfaces seems quite risky to me.
In the end, it can be difficult to have completely orthogonal functionality in different interfaces and there will always be a bit of overlap.
Note that, even if we decide to update network-manager, such a change would take a while to be generally available. So while we’re having that discussion, +1 to auto-connect both, and thank you for the additional information.
Thanks @abeato. @jdstrand, if network-manager provides the ability to do what ip does, does it not also make sense to have it allow access to ip ? Or am I missing something?
The ip command and everything it is capable of doing to the system is granted via the network-control interface, which the network-manager snap already has. By design, network-control is a superset of network-observe (network-control allows reads and writes as opposed to just reads (the ip command can be used for just status/reports/reads with network-observe)). In control vs observe interfaces, the pattern is generally read/write vs read, respectively, since almost everything that writes needs to also read and we don’t want to require people to plugs both to get write and read. In this manner, @abeato is correct to say that the snap on the whole already has the permissions of network-observe, but the hooks don’t need the write access, only the read, so network-observe makes sense.
I believe all questions related to this have been answered. @reviewers - can others please vote?
In this manner, @abeato is correct to say that the snap on the whole already has the permissions of network-observe, but the hooks don’t need the write access, only the read, so network-observe makes sense.
This is correct, the different interfaces that NM uses already provide the permissions of network-observe. And yes, the hooks do not need the write access.