I just checked how dbus notification are working on MATE with a snapped app and got this error: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: An AppArmor policy prevents this sender from sending this message to this recipient; type="method_call", sender=":1.109" (uid=1000 pid=2190 comm="telegram-desktop " label="snap.telegram-desktop.telegram-desktop (enforce)") interface="org.freedesktop.Notifications" member="Notify" error name="(unset)" requested_reply="0" destination="org.freedesktop.Notifications" (bus)
(there are also the same errors for all the other methods on the interface, like GetCapabilities and so on)
I guess it’s because MATE doesn’t have notification daemon process running all the time in background, it’s dbus activatable instead and stops running multiple seconds after last notification was hidden.
No, it requires peer=(label=unconfined), so notification daemon should running or should have AssumedAppArmor=unconfined in its systemd unit file, while it doesn’t have a systemd unit file and dbus generates it, so snapd blocks the access. There should be lines like xdg-desktop-portal has
Can you elaborate on what specific D-Bus access is needed in order to active the notification service on KDE? i.e. for portals, you pasted the bit that’s needed, and we can probably add more to enable notifications if needed, but we need to know what specific D-Bus rules to allow this.
It’s not related on KDE, as you can see in initial post, it’s related to MATE. MATE has an activatable notification service and snap denies access to it until it’s running, just like it was with portals until that fix
I guess you can create some simple snap that will do something like busctl --user call org.freedesktop.Notifications /org/freedesktop/Notifications org.freedesktop.Notifications GetServerInformation and you will get an access denied error on MATE if notification daemon is not running (but is activatable)
As of the D-bus spec revision 0.30 in 2016-11-28, it seems that dbus-daemon service files can indeed specify AssumedAppArmorLabel, see:
Define the jargon terms service activation and auto-starting more clearly. Document the SystemdService key in service files. Document how AppArmor interacts with service activation, and the new AssumedAppArmorLabel key in service files (dbus-daemon 1.11.8). Clarify intended behaviour of Properties.GetAll. Use versioned interface and bus names in most examples.
Perhaps upstream MATE can be convinced to add this AssumedAppArmorLabel key to their notifications dbus-daemon service configuration file?