Desktop notifications denied in Ubuntu MATE

snapd
1

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

But

$ 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 ?

2

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.

3

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

4

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).

5

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?

6

If you’re talking about https://github.com/canonical/multipass/issues/2258, 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
7

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.

8

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).

9

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

Still no notifications, of course.

10

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