This sounds similar to the shift in the D-Bus API usage similar to what happened with NetworkManager: the newer client libraries are using the D-Bus ObjectManager interface, which the AppArmor policy generated by snapd is blocking.
The fix would probably look similar to @alexmurray’s fix for the network-manager-observe interface:
Thank you @jamesh for this update… Btw , i cannot see AppArmor error using “snappy-debug” … May i know, how can i get the fix(preferably through snapd ‘edge’ channel) , so that i can confirm it ? Thank you again !!
I think that the problem here is not apparmor, but the DBus policy for the modem-manager interface, that is quite restrictive if you are not root:
I think this can be changed to be more in line with what is done for the deb package, but even in that case, you will need root access for some actions - that is enforced by policykit rules. And iirc correctly this snap does FCC unlocking, so probably that action needs root? Why is it a problem to require root permissions in this case?
Yes , this SNAP performs FCC unlocking. However , we are currently extending it to perform FCC unlock and also to maintain SAR level for FCC certification.
When this issue occurs , then “Mobile broadband Settings” gets disappeared from system tray . I am not user why it breaks gnome-control-center but it looks like some kind of communication is broken between ModemManager and Network manager.
However , if i use "nm-connection-editor” command then i am able to connect to network . So, it looks like Network manager is able to communicate with Modem.
I am actually not sure of why this issue is caused and hoping this might be fixed with your PR.
Modem Manager is compiled separately as Ubuntu 20.04 had old MM . But , i have also tested using default MM of Ubuntu 21.10 and face same issue. I had only added below plugs in snapcraft.yaml file
plugs:
- modem-manager
I will perform testing using your PR and update , if i can reproduce this issue now or not.
Thank you !!
So I have been looking into this issue some more today - and it appears this is an issue in snapd itself - essentially when a snap is installed which plugs modem-manager and the modem-manager interface is connected, snapd generates a DBus policy at /etc/dbus-1/systemd/snap.<snap-name>.<command-name> for this which states:
<!DOCTYPE busconfig PUBLIC
"-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
"http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<!-- This file was automatically generated by snappy -->
<busconfig>
<policy context="default">
<deny own="org.freedesktop.ModemManager1"/>
<deny send_destination="org.freedesktop.ModemManager1"/>
</policy>
On a classic system with modem-manager already installed however, there is already DBus policy present for modem-manager at /etc/dbus-1/system.d/org.freedesktop.ModemManager1.conf - and this has a lot of different rules already regarding access to or ownership of ModemManager via dbus. In particular this also defines it’s policy within a <policy context="default"> block.
The problem though is that the policy generated by snapd now conflicts with the system installed policy - and it is not really clear to me how dbus resolves it (the documentation doesn’t really talk about how dbus handles multiple files - but it does say that Multiple policies with the same user/group/context are applied in the order they appear in the config file - which may mean that the snap generated policy completely overrides the default policy for ModemManager.
So in this case, I think perhaps the best course of action is for snapd to only generate this policy on Ubuntu Core systems only (since in this case ModemManager itself is a snap and so it probably makes sense to still generate this default policy).
Thanks a lot @alexmurray for this PR .
I will test this PR by downloading snapd locally . May i know , where i can find instructions to compile/install snapd locally from source ?
Thank you !!
A snapd snap containing this fix is built as part of the github actions checks run against the PR - see Testing snapd fixes for details on how to download this and use it for your testing.
Hello @alexmurray - I have tested snap with your PR and its working fine now in “strict” confinement. We will perform full testing again once changes are in edge channel.
Thanks a lot for your support.