Add AssumedAppArmorLabel to dbus service file

[lucyllewy]

Snap packages are unable to trigger the notification daemon in a fully confined package, because the snapd apparmor rules state that the target of the dbus call must specify that it is labelled unconfined. See https://forum.snapcraft.io/t/snapd-doesnt-allow-notification-daemon-to-be-activatable/22912/1 for the details.

• Add AssumedAppArmorLabel rule to dbus service file

[raveit65]

How , can i test that it works? I am using snapd on fedora and i have installed a few application from snapstore.

[lucyllewy]

You need to find a strictly-confined snap that triggers a desktop notification and cause it to do so. The notification daemon needs to be not-running, but loaded, at the time of the triggering to validate that the update works because once the daemon is running I believe apparmor can correctly detect the label.

You also need to ensure that your system is capable of correctly forming the strict confinement, because not all kernels are able to do so - you can check with snap debug confinement which should print strict if strict confinement is supported.

[raveit65]

You need to find a strictly-confined snap that triggers a desktop notification and cause it to do so.

Which application from snapstore can do that? I don't want to search at the whole snapstore :)

[raveit65]

[rave@mother ~]$ snap debug confinement
partial

So, i can't test it ?

[lucyllewy]

So, i can't test it ?

You can only test that it doesn't regress with that system. This is because the dbus isn't being mediated by apparmor in partial confinement, so the call will always succeed where on a strict-capable system it will fail.

[ricab]

Which application from snapstore can do that?

The Multipass GUI tries to issue a notification on first startup. When installed as a confined snap, it currently fails to do so on MATE, unless the service is already running. This should hopefully fix that, so you could use Multipass to verify :slightly_smiling_face:

[raveit65]

Ok, on fedora systems selinux Mandatory Access Control is running and not apparmor, in result i can only test that adding AssumedAppArmorLabel=unconfined doesn't break notification-daemon on systems without apparmor. This needs to be tested from someone who has Ubuntu running, maybe Martin Wimpress? @flexiondotorg

[raveit65]

@diddledani Can you please update commit message with a meaningful valid description? Update org.freedesktop.mate.Notifications.service.in is what you did, but not what commit does ;)

[lucyllewy]

done :-)

[raveit65]

@diddledani I suggest to ping Martin at ubuntu-mate at discord for testing. He is one of the owner of MATE at github.

[flexiondotorg]

I confirm this patch fixes the issue. I've used Ubuntu MATE 21.10 (devel) with this patch applied to mate-notification-daemon 1.26.0-0ubuntu2.

[raveit65]

@flexiondotorg this needs push to 1.26 branch, or not?