If a user has switched to the confined snap for fwupd then they need to have the snap-store be able to communicate with it. I find it doesn’t work with following error:
23:09:39:0252 Gs not handling error failed for action refresh: An AppArmor policy prevents this sender from sending this message to this recipient; type="method_call", sender=":1.287" (uid=1000 pid=25566 comm="/snap/snap-store/959/usr/bin/snap-store" label="snap.snap-store.snap-store (enforce)") interface="org.freedesktop.fwupd" member="GetRemotes" error name="(unset)" requested_reply="0" destination=":1.270" (uid=0 pid=21909 comm="/snap/fwupd/5533/libexec/fwupd/fwupd" label="snap.fwupd.fwupd (enforce)")
23:09:39:0254 Gs not handling error failed for action get-updates-historical: An AppArmor policy prevents this sender from sending this message to this recipient; type="method_call", sender=":1.287" (uid=1000 pid=25566 comm="/snap/snap-store/959/usr/bin/snap-store" label="snap.snap-store.snap-store (enforce)") interface="org.freedesktop.fwupd" member="GetResults" error name="(unset)" requested_reply="0" destination=":1.270" (uid=0 pid=21909 comm="/snap/fwupd/5533/libexec/fwupd/fwupd" label="snap.fwupd.fwupd (enforce)")
I find that connecting the slot and plug between the two fixes it.
snap connect snap-store:fwupd fwupd:fwupd
I feel that snap-store needs to automatically connect these two from the store. Can you please make that happen?
If I understand it properly, you want the snap-store snap to auto-connect to the fwupd slot, that may be provided either by the fwupd host service or by the fwupd snap.
In that case, if we grant snap-store auto-connect to the fwupd interface it will work properly in case that only one slot is available in the system (i.e. only the system service or the snap are installed). However, if the slot is provided by both, the system and the fwupd snap, the auto-connection won’t work (as it is not clear which slot the snap should plug into).
It is the same problem reported here for Brave and cups. This PR fixes the issue for the cups-control interface, giving preference to the slot provided by the host when available. Maybe we will need to define it in a more generic way to support other interfaces.
I’m not 100% sure, but there might be a possible workaround. We may be able to force the snap to ALWAYS connect to same slot (by preventing the connection to the other). The downside would be that if you decide to always connect to the host slot, it won’t work if the service is not installed in the host, and if you decide to connect to the snap, the fwupd snap will be always installed even if the service is available in the host. I would suggest you to contact the snapd team to discuss about it and a the possible more generic long-term solution
