Autoconnect requests for pulseaudio

We are updating the pulseaudio snap and would like these interfaces autoconnected:

  • audio-playback and audio-record -> these two are for replacing the deprecated pulseaudio interface.
  • bluez -> To be able to talk to the bluez daemon to control bluetooth audio devices
  • hardware-observe, alsa -> needed for better handling of ALSA drivers

Note that we still need the pulseaudio interface autoconnected until these changes are released to all channels.

It is not a problem to grant the pulseaudio snap the slot access for audio-playback and audio-record (and continue with pulseaudio) but we’ll need to decide how clients should connect to the snap. audio-playback is easy: auto-connect, but audio-record exists solely for the purpose of pulseaudio (or another audio server) to mediate recording by querying snapd to ask if the connecting process is unconfined, classic or has the pulseaudio/audio-record interface connected (ala Ubuntu’s mediation patches). Therefore, to make audio-record meaningful, you need the mediation patches.

You’ll find that once you add these patches, pulseaudio will reach out to the snapd socket and your snap will need to plugs snapd-control (like the recent Request: CUPS Snap ("cups") auto connection to avahi-control, raw-usb, cups-control, and system-files interfaces request), but per @pedronis, the security and the desktop teams, we won’t grant you this access. What is needed is for snapd to grow a new interface so a snap can plugs it and snapd control can mediate the access to its APIs. This is planned and something @kenvandine was going to assign to the desktop team, but I suggest you reach out to him to decide how to proceed (ie, I don’t know their plans or progress; you may be able to help). Without the mediation patches and this change to snapd to allow you to query it, -1 for slotting audio-playback and audio-record (since access to the pulse socket, which audio-playback would grant, would grant recording and it would be way better to have all these things in order instead of granting slot access ahead of it). Once it’s implemented (even just in edge), I’ll be +1.

+1 for to auto-connect alsa and hardware-observe (pulseaudio obviously needs them).

+1 for auto-connecting pulseaudio to bluez as well.

@reviewers - can others please vote on alsa, hardware-observe and bluez?

To be clear I think there are two parts to that:

  • one is an API or snapctl feature to make the query, something like perhaps:

    snapctl is-connected --pid PID|--security-tag SECTAG slot|plug

    that would let the snap query whether there’s a snap connected to the slot/plug on the other side
    of that PID/security tag, it might also have to instead tell that PID is unconfined?

  • an interface that let a snap access that query capability for its plugs/slots for some set of interfaces, we could also separately decide though that some *-control or *-support interfaces come with the implicit permission for the control slot respectively support plug snap to make queries for the corresponding consumer interface

[cc’ing @till.kamppeter as this ties into the CUPS snap]

I think the process ID version of this call would be fine for CUPS to classify requests from other snaps. It would need more than this to allow requests from unconfined processes on the host system, as would be the case if we were using the snap on future Ubuntu Desktop releases.

I realise that an “is this pid a snap?” call reveals a lot more information about the system than the snapctl is-connected call you’ve proposed. That might be something we’d want to lock down, rather than expose to all snaps.

First of all as the 2nd part explain, none of this would be exposed to all snaps by default. Also I didn’t think of this but for the unconfined case it could also simply answer yes/true instead of special casing.

Also to be clear slot|plug here must be one of the slots/plugs of the querying snap.

I understand the proposal was to check for if the remote process was connected to the snap’s own named plug or slot.

Treating unconfined processes the same as connected snaps would likely be fine for the CUPS use case. It’s hard to say what other potential users of such an API would want.

As far as access control to the command go, there are two reasonable options I can think of:

  1. require the calling snap to have a connected plug of some marker interface granting access. This would allow access to be granted via assertions from the store.
  2. require the call to reference a slot for a whitelisted interface. This might require that publishing snaps with the slot be restricted by the automated review process.

(1) might be more useful for experimenting with new use cases for the command. (2) has the benefit that the command is guaranteed to be available in cases we’ve determined it is needed.

+1 from me to for auto-connect of alsa, hardware-observe and bluez for pulseaudio since these are all needed for core pieces of functionality for the snap.