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:
- application asks x-d-p for access to a camera
- x-d-p asks the user if they want to grant access (if they haven’t already done so)
- 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.
- 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 callsaa_getcon
to determine whether it is running as a snap under AppArmor confinement, which fails otherwise. This is needed to enforce theaudio-record
interface microphone access restrictions. I also seeoperation="ptrace" ... requested_mask="read"
denials from thepipewire-bin
andpipewire-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.
- hardware-observe: