Snapd doesn't allow notification daemon to be activatable

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.

This access is allowed by the desktop interface. Does your app plug that interface at all?

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

A month has passed and no solution :frowning:

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.

Also relatedly, I assume this is different from https://github.com/snapcore/snapd/pull/9840? Or does that PR fix this issue?

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)

Thanks for that information, and to be clear upstream in MATE don’t want to add AssumedAppArmor=unconfined to the unit file for their notifications daemon ?

They don’t have unit file, I see it’s generated automatically by dbus

Hmm, I’m not familiar with such mechanisms to automatically generate a D-Bus activated service without creating a unit file somewhere, is this process documented somewhere ?

I guess dbus daemon contacts with systemd APIs and creates transient units

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?

I’ve filed a PR upstream in Mate-Desktop

Update org.freedesktop.mate.Notifications.service.in by diddledani · Pull Request #201 · mate-desktop/mate-notification-daemon (github.com)

1 Like

But that won’t help to systems with older MATE even if this will be accepted. This also won’t help for other projects with activatable daemons that don’t care about AppArmor.