Request auto-connection of various interfaces for the pipewire snap

I’d like to request a few interface auto-connections for the Pipewire snap.

It’s possible we could eventually get rid of system-observe by bundling the subset of permissions it needs into e.g. the audio-playback permanent slot rules, but for now it would be easiest to use this interface for now.

For the camera related permissions, we don’t expect many snaps to talk to Pipewire directly. Instead they will talk to xdg-desktop-portal, which will perform the access control. The process looks something like this:

  1. application asks x-d-p for access to a camera
  2. x-d-p asks the user if they want to grant access (if they haven’t already done so)
  3. x-d-p creates a new connection to Pipewire and installs an access control filter limiting that connection to only the nodes associated with the camera.
  4. x-d-p uses file descriptor passing to send this pipewire connection to the application.

This is roughly the same as how screen sharing currently works in the Firefox snap.


  • name: pipewire
  • description: the Pipewire media server, packaged for use on Ubuntu Core Desktop
  • snapcraft: pipewire-snap/snap/snapcraft.yaml at main · canonical/pipewire-snap · GitHub
  • upstream: https://gitlab.freedesktop.org/pipewire/pipewire
  • upstream-relation: the snap is published by the canonical account
  • interfaces:
    • hardware-observe:
      • request-type: auto-connection
      • reasoning: this is required to detect what hardware is available that should be exposed by the server.
    • system-observe:
      • request-type: auto-connection
      • reasoning: without this, we run into problems with access control. The pipewire-pulse daemon calls aa_getcon to determine whether it is running as a snap under AppArmor confinement, which fails otherwise. This is needed to enforce the audio-record interface microphone access restrictions. I also see operation="ptrace" ... requested_mask="read" denials from the pipewire-bin and pipewire-pulse services, which seems to trigger from some of the information they try to access about clients. I don’t think they actually call ptrace though.
    • alsa:
      • request-type: auto-connection
      • reasoning: Pipewire provides access to sound devices, so should have access to the sound subsystem.
    • bluez:
      • request-type: auto-connection
      • reasoning: To enumerate and provide access to Bluetooth sound devices, Pipewire needs to be able to talk to the bluez snap.
    • camera:
      • request-type: auto-connection
      • reasoning: In addition to sound, Pipewire can mediate access to video streams. This is required to access V4L2 cameras on the system.
    • media-control:
      • request-type: auto-connection
      • reasoning: to expose some modern cameras via libcamera, Pipewire needs to access the media control devices used to inspect and wire up the sub-devices that comprise the camera.

+1 from me for auto-connect of all hardware-observe, system-observe, alsa, bluez, camera and media-control interfaces to the pipewire snap as these are needed for regular operations.

1 Like

+1 from me as well for auto-connection of hardware-observe, system-observe, alsa, bluez, camera and media-control interfaces to snap pipewire.

1 Like