I looked into the status of pulseaudio and mediating access to audio recording and submitted https://github.com/snapcore/snapd/pull/5504. To quote the PR:
When the pulseaudio interface was first written, it was planned that it would only support playback and that recording would come later. This was reflected in the interface documentation at Interfaces until it was corrected today.
On Ubuntu Touch, pulseaudio was modified to include patches that would not allow record but these patches were never upstreamed. Classic Ubuntu, its flavors and derivatives (since Ubuntu 16.10) include a patch to deny audio recording unconditionally when the connecting application is a snap (https://launchpad.net/bugs/1583057), but this patch is broken (https://launchpad.net/bugs/1781428).
Upstream prefers to implement access controls instead of the patch included in
and patches have been submitted, but still not upstreamed:
Fedora 26 and later apparently have these patches with portals now supporting
Until snapd/pulseaudio can mediate access to recording everywhere, we should be
clear on what may be allowed.
So, the status is essentially that upstream does not include the necessary patches to mediate recording and Fedora and Ubuntu are doing something different (or at least Ubuntu tries to). Ubuntu’s unconditional deny patch should not be disabled at this time since strict mode applications like chromium, firefox, etc would no longer be able to record audio.
IMO, snapd should support something like:
plugs: pulseaudio: allow-record: true|false
where playback continues to be auto-connected and specifying
allow-record would trigger manual review.
@willcooke (cc @niemeyer) - is this something that the desktop team could look into and put on the Roadmap to drive it to conclusion? This is IMO an important confinement gap that needs to be addressed. Perhaps @jamesh has some insight with his recent work on portals?