As part of getting applications working in a confined desktop I’ve been looking at snapping more complex that the standard leaf apps (e.g. calculators, text editors). I’m trying to snap d-spy, which is a development tool for browsing D-Bus.
This app requires full read/write access to D-Bus to be useful and on a non-confined desktop this would probably work best as an unconfined snap.
I’m proposing we add a new snap interface that allows full D-Bus read/write access. This would have an implicit slot on both desktop and core, and require approval to be autoconnected. In the case of d-spy, I would expect it to be autoconnected, as installing without this interface is not useful. There would likely only be a handful of apps that would make use of these, almost certainly all development tools.
Does an interface like this make sense in snapd? Are there other methods of making development tools work in a confined desktop?
This particular app is the kind of one that would satisfy the classic confinement review guidelines as a “debug tool”. But it’s also the kind of thing that would be a lot easier to package and maintain as a strict confined snap (assuming it had the access it needed to operate).
In addition to allowing to run on Ubuntu Core systems, allowing apps like this to run in a safer mode than classic confinement seems like a worthwhile goal. I think the main issue would be to ensure that regular app developers don’t reach for this in preference to the existing dbus interface.
I was trying to think of an appropriate name for the interface. dbus-control was the first name I tried, as there seems to be a convention of interfaces with this extension for things that can be read/written (the -observe suffix being used for access with only read). As James said, we wouldn’t want regular app developers to accidentally use this interface, so perhaps something like dbus-full-access or dbus-read-write might convey this better.
