Flatpaks access the PipeWire socket via filesystem access to xdg-run/pipewire-0. Of course, this grants access to audio playback and recording, as well as screen capture. But I’ve noticed that, the majority of the time, Flathub maintainers request it be marked :ro.
Some apps, like Discord, WiVRn, and GPU Screen Recorder are exceptions. All three of these have video related functions, like Discord’s screensharing, so perhaps that’s why. Except it’s not, because apps like Fluxer and Steam have it read-only, and their screensharing and recording functionality is fine, and Discord has no issues read-only either in my experience. There are also apps which directly manipulate streams, like EasyEffects, which have no write access. It’s also seemingly not an instance of older apps just not being updated yet, as there are relatively new apps where this was not questioned, like ossia score.
There’s obviously a distinction, since it’s frequently requested to add :ro in manifests… but what is that difference? What does having write access to the PipeWire socket let you do? Is it more dangerous in any way?
I have searched “pipewire” on this forum, on the GitHub flatpak and flathub organizations, and “pipewire” “ro” on Google, and opened every single result. I have not been able to find any information about this, or even anyone questioning this before me. I feel as if I must be missing something obvious. So I’m asking here, in hopes any answer I might get will be publicly documented should anyone follow in my footsteps.
Heya,
I wonder if opening the socket in read-write mode would maybe allow to control the pipewire graph ?
e.g. you would only need :ro to read/write audio or video signals, but you’d need the full permissions if you wanted to do something like helvum or qpwgraph which is going to be able to manipulate the whole graph.
On the ossia score side, the features that matter are:
- audio capture and recording
- video capture and recording
1 Like
A great theory, I had neglected to try that. I tested Helvum, qpwgraph, and coppwr; and they’re all able to modify the graph just fine when I manually set it to :ro. So that’s not it…
I’m actually realizing, some of these apps weren’t using PipeWire on my setup at all. Discord uses the portal for screensharing, plays sound through Pulse, and needs device=all for webcams. Discord requests the permission for Steam Deck support. Doesn’t really affect my question though.
Read-only access to socket files is sufficient to use them in linux. This isn’t obvious for most people so they didn’t realize that when adding permissions.
But is there ever a reason a flatpak would want to access a socket file? What would write access allow them to do? Why do Flathub maintainers not always enforce that?
Non malicious flatpaks don’t have any reason for rw access to socket file. Nobody proposed blocking that yet so it isn’t blocked. If you want to contribute then you may send PRs to relevant apps adding :ro to socket files permission. After all apps are fixed then you may propose enforcing that to flathub.
1 Like
In that case, I know what I’m gonna do today 
Thank you for answering!