Skip to content

Support separate Pipewire socket for normal clients & session manager

P V requested to merge pvir/wireplumber:restrict-socket into next

Support configuration where PW module-access punts all client access decisions to WP, so that there is no race where PW module-access has already granted all permissions before WP access rules run.

PW needs to know who is the session manager (so it can give it all permissions), and the idea is to do this by having WP connect to separate pipewire-manager-0 socket, while normal clients use pipewire-0. See pipewire!1732 (merged) and pipewire!1731 (merged)

This seems to need three things:

  • Support pipewire.access == "default" value that we'd use for normal clients
  • Use the pipewire-manager-0 socket
  • Handle permission transitions (unrestricted -> flatpak, unrestricted -> pipewire.client.access) on SM side.

The new access value is since we need a value that means "session manager decides" and "unrestricted" and "restricted" had already different meanings.

Changing the socket in principle is as simple as PIPEWIRE_REMOTE=pipewire-manager-0 wireplumber.

Session manager needs to handle the permission transitions, because module-access knows nothing about the meaning of the labels. E.g. if things like restricted -> portal (no) or restricted -> flatpak (maybe yes) or default -> flatpak (yes) are allowed. Also, it's probably better if module-access does not have any complicated pattern matching engine itself, and instead the session manager does it.

This has the drawback that pipewire.access is then in 1-to-1 correspondence with which socket the client connected from, and does not reflect the final permissions, but that is probably OK. So I made wireplumber here set pipewire.access.effective to the final resolved permission level.

  • How to decide, and in which layer, whether WP uses pipewire-manager-0 or pipewire-0.
  • We'd maybe like to make the two-socket configuration the default one. How to do this?
Edited by P V

Merge request reports

Loading