Desktop notifications denied in Ubuntu MATE

In Ubuntu MATE, Apparmor denies desktop notifications to the Multipass GUI, even after adding the desktop plug:

= AppArmor =
Time: Sep 27 16:20:41
Log: apparmor="DENIED" operation="dbus_method_call"  bus="session" path="/org/freedesktop/Notifications" interface="org.freedesktop.Notifications" member="Notify" mask="send" name="org.freedesktop.Notifications" pid=57117 label="snap.multipass.gui"
DBus access


$ snap connections multipass | grep desktop
desktop            multipass:desktop            :desktop  

Do I need anything else to make this work? I suppose there is no point adding a dbus plug on top of desktop, which should already take care of notifications, right? Is this perhaps another occurrence of Snapd doesn't allow notification daemon to be activatable ?

btw, if you need a workaround, I know one: you can add a org.freedesktop.DBus.StartServiceByName call before calling any method on org.freedesktop.Notifications.

This does indeed look to be the same issue. I’ve filed a PR upstream to fix it when it trickles down to users.

Thanks for the tip. We use org.freedesktop.Notifications indirectly (through Qt) and I would rather avoid reaching into DBus details just to work around. But, with your tip, I was able to get notifications after triggering the service, which allowed me to disentangle this from the other issue we’re having on MATE (missing icon).

Thanks, I hope it goes through. I’ve pointed them to Multipass as the test subject they were requesting.

Shouldn’t activatable notifications be supported by snapd all around though?

If you’re talking about, it’s due to the inability to scan processes. The thing is Ubuntu MATE replaces MATE’s proper SNI support with Unity’s AppIndicators. AppIndicators support only a part of SNI spec (e.g. no IconPixmap support that Qt uses, that’s why you see the stub instead of the icon). Qt has a workaround, it scans processes and tries to find indicator-application process. If it finds it, Qt assumes AppIndicators are in use and saves the pixmap to a temp directory with specifying it as IconName (what is supported by AppIndicators).

1 Like

Thanks @ilya-fedin, very interesting and useful! I hadn’t pay much attention to the ptrace denial because I got it under GNOME as well. I guess not finding the process just happens to be the right outcome there.

I am producing a snap with system-observe now to see if that helps.

I haven’t inspected the ptrace, I ran into this long time ago and found this by looking at Qt code. As a result, I was forced to grow a custom SNI protocol implementation in the application I was encountered this instead of using QSystemTrayIcon (since probably no one would allow me to request auto-connect of system-observe just for that reason).

OK, I confirm that makes the icon show up, thanks again!

Still no notifications, of course.

A funny thing is that this is not a problem for gtk applications. They use libnotify that uses GDBusProxy that does StartServiceByName call automatically.

1 Like