D-Bus activation for snaps

snapd
1

(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.freedesktop.secrets and 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?

2

@jdstrand do you have input on this?

3

The change required is a code change to dbus-daemon itself and there isn’t something that snapd or the client snap can do.

In short, when the DBus changes were upstreamed, upstream insisted on AssumedAppArmorLabel being present and failing closed when not instead of defaulting to ‘unconfined’ when not present. We argued against this at the time. I would love to see this changed, but that discussion needs to happen in upstream DBus since distros are unlikely to distro patch for this change.

1 Like