PipeWire sound server permission marks application as potentially unsafe

[ilya-fedin]

According to flatpak/flatpak#5130 (comment), --filesystem=xdg-run/pipewire-0 is the right permission for PipeWire acting as sound server yet flathub website marks applications as potentially unsafe with the following:

PulseAudio permission doesn't cause such a problem.

[orowith2os]

PipeWire isn't just a sound server - it handles screen sharing, cameras, and all sorts of multimedia devices too. It should 100% be marked as potentially unsafe. How it's marked as potentially unsafe is the topic for discussion here.

[ilya-fedin]

Do you mean flatpak applications should avoid pipewire and use pulseaudio to be safe? I want to get rid of this for my application, not a clearer statement. I don't think my application should be marked as such just because it uses the more modern API.

[orowith2os]

I don't mean anything - it's up to the apps to choose what they want to use here. But safety warnings don't really matter right now, until quite a few portals land (an expanded Device portal, for one).

[ilya-fedin]

an expanded Device portal, for one

It seem to stuck for two years already?

[ilya-fedin]

I'd wonder what's the recommended approach to avoid application being marked as potentially unsafe for now 🤔

[orowith2os]

It seem to stuck for two years already?

Contributions welcome.

[razzeee]

@ilya-fedin can you try if this also happens in gnome software (ideally gnome software 45)

if it does happen there:

• open an issue over there, similar to https://gitlab.gnome.org/GNOME/gnome-software/-/issues/2315 and let us know of that issue

if it doesn't, I probably missed it when I implemended this.

[razzeee]

It would also be great to let us know which apps you were able to test this with, I'm not feeling like I should have to hunt this down :)

[ilya-fedin]

@razzeee I don't think I can, I'm a NixOS KDE user, installing GNOME software will likely be a big headache (will require activating addition services in the system config but I don't want to rebuild my system now)...

[razzeee]

@ilya-fedin I can probably check it for you, I have a vm and a laptop already on 45, but I will need an app with that permission set

[ilya-fedin]

https://github.com/search?q=org%3Aflathub%20--filesystem%3Dxdg-run%2Fpipewire-0&type=code
Personally I was checking org.telegram.desktop

[razzeee]

Yeah, this seems to be an oversight in g-s too, I think. I'll open an issue over there.

[razzeee]

https://gitlab.gnome.org/GNOME/gnome-software/-/issues/2329

[razzeee]

https://gitlab.gnome.org/GNOME/gnome-software/-/merge_requests/1811/diffs is the current state of gnome software

[ilya-fedin]

Do I understand right that pulseaudio access will still be displayed as safer than pipewire access?

[razzeee]

I don't think so, but can you point me to an example/finish-arg?

[ilya-fedin]

finish arg of what? pulseaudio access? --socket=pulseaudio. Almost every flatpak package has it yet flathub doesn't present it in any way nor marks application as potentially unsafe due to it, unlike pipewire.

[razzeee]

As far as I know, that only allows audio playback (at least if https://docs.flatpak.org/en/latest/sandbox-permissions.html#standard-permissions is right) which should be safe.

The pipewire file, allows you to play sound, record sound, access the camera, the screen contents etc.

[ilya-fedin]

It also allows to record the sound. Or apps like Discord wouldn't work. It's an unsandboxed access to the pulseaudio socket, just determining the socket path on your behalf.

[razzeee]

Right, can you report this to gnome software and link us here to that issue?

[ilya-fedin]

I'm not sure I can given that I don't use gnome software? I wouldn't be able to answer gnome software-specific questions.

[razzeee]

Created https://gitlab.gnome.org/GNOME/gnome-software/-/issues/2394

[ilya-fedin]

Lurking regarding the --filesystem=xdg-run/pipewire-0 change in gnome-software I noticed https://gitlab.gnome.org/GNOME/gnome-software/-/commit/56c3a9b784da23f2a60f18b807bd31f3701dee78, is flathub going to do the same? It looks quite weird given that --devices=all provides access to all the /dev including /dev/dri and /dev/fb* that should give the screen grabbing (and likely also modifying) just as well as pipewire. I would expect that to be mentioned in the existing all-device access rather than a separate item.