Dbus confinement rules -- what does the snapcraft store need?

I am working on some software that is intended to be deployed to a fleet of IoT devices.

We currently have several executables in our snap that communicate with each other via DBus.
Ubuntu core has only a “system” dbus service running, so we have been using the system bus.

Using this documentation:


We have built snaps that we can install on the devices and run.

When we try to push the snaps to the snapcraft store, we get tagged for human review

  • human review required due to ‘deny-connection’ constraint for ‘slot-attributes’ from base declaration

Is there any documentation for the “best case” way to provide D-Bus service snaps on Ubuntu Core?

Changing to a session on DBus for our snaps still tags us for human review (and is more complicated than using the system bus on Ubuntu Core). I can use dbus-run-session to start a DBus session, but I would have to manage it’s lifetime.

Wendell

You are doing it. :slight_smile: The fact that this flags manual review doesn’t mean you’ve done something wrong. Since a snap could claim any name, our public store processes ensure that the well-known DBus name your snap is claiming makes sense for your snap. Your snap simply needs a snap declaration in the store that allows your snap to claim the dbus name and after that it will pass automated reviews.

I see a private snap that seems to match your forum username and can say that the chosen well-known DBus name in that snap is fairly generic, and seems unrelated to your publisher name and snap name. The DBus specification recommends a reverse domain name scheme and people often use this in their snaps (eg, com.yourdomain.YourService). You can also just use the snap name in the well-known name (eg yoursnapname.Service).

1 Like