(there’s another topic about D-Bus activation, but it’s old and not entirely related, so I’m starting a new conversation here)
The chromium snap pokes the
org.kde.kwalletd5 services over D-Bus to check for the availability of a suitable keyring to store encrypted passwords (code).
This works well if the services are already running. If they aren’t, the assumption is that D-Bus activation should spawn them. But it doesn’t.
@ijohnson suggested that the problem looked similar to bug #1749000, and that adding
AssumedAppArmorLabel=unconfined to the D-Bus service files might fix it. And indeed with that the problem goes away.
It doesn’t seem reasonable to patch every single D-Bus service file out there (and SRU’ing the change) to make D-Bus activation work again.
Is there a different approach where this could be made to work by only changing the client snap, or snapd itself?