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.

3 votes for, 0 against for auto-connection of alsa, hardware-observe and bluez for pulseaudio. Granting. This is now live.

In addition, I granted the ability to provide (slot) the audio-playback and audio-record interfaces, but left them as manually connected since the pulseaudio snap can’t mediate the access to audio-record without the snapd query interface @pedronis and @jamesh (and I) discussed.

Great, thanks for the reviews

I’ve put up a first attempt at the API proposed by @pedronis here:

[waiting to see whether I got the spread tests right]

This only implements the process ID variant, since that seems like the better fit for services like Pulse Audio and CUPS. In general a daemon will require the same or less access to discover the peer’s process ID compared to discovering its security label.

This version does not include any restrictions on what snaps can use --pid, and returns false for non-snap pids. Both probably need to change before it lands.

CUPS is supposed to allow access from any non-snapped process and any classic-mode-snapped process in addition to standard-snapped processes plugging to “cups-control”, so either the mentioned command should return “true” in all these cases or have special answers for non-snapped and classic-mode-snapped processes.

@jdstrand a review for would help also on fully confined pulseaudio.

@abeato is there an ETA for the updated pulseaudio snap with audio-playback? Latest version on edge (8.0-4, r60) doesn’t have it yet. Thanks :slightly_smiling_face:

well, the PR above was merged in sept … and i see the pulse changes have also been merged into master:

not sure why it isnt in the edge build of the pulse snap yet …

(i’m personally waiting for the bluez plug)

I have now published a new version of the snap in edge and beta channels.

1 Like

and i can confirm it works just fine … i could even drop the old pulseaudio plug in my snaps and finally can use “audio-playback” instead … bluez audio works too with a bit of client side scripting (in case anyone needs to do something similar, here is a command-chain wrapper that sets it up):