LIBPIPEWIRE-MODULE-ACCESS(7)

💖 libpipewire-module-access — the access module (from the Miscellaneous Information Manual, bestie) 💖

okay so real talk, this one lives in the Miscellaneous Information Manual and it's the bouncer at the club that is your PipeWire graph. let's get into it 🎀

---

✨ NAME ✨

libpipewire-module-access — Access. that's it, that's the name, short and iconic 💅

---

🦋 DESCRIPTION 🦋

so the access module does access checks on clients. that's the whole vibe.

and here's the thing — the access check is only performed once per client. once it's done, every check after that just returns the same resolution. no reruns, no sequels, periodt. ✨

the permissions that get assigned to a client are configured as arguments to this module (scroll down, babes, it's all there 👇). anything beyond unrestricted access gets delegated to an external agent — usually the session manager. like, the module handles the basics and the session manager is the manager-manager. iykyk.

this module sets pipewire.access like so:

• If the access.legacy module option is not enabled:
  • the value defined for the socket in the access.socket module option, or "default" if no value is defined.
• If access.legacy is enabled, the value is:
  • "flatpak": if the client is a Flatpak client
  • "unrestricted": if the pipewire.client.access client property is set to "allowed"
  • the value of the pipewire.client.access client property, if set
  • "unrestricted": otherwise

if the resulting pipewire.access value ends up being "unrestricted", this module gives the client ALL the permissions to access ALL the resources. main character energy, truly. otherwise? the client is forced to wait 🫠 — it sits there until an external actor, like the session manager, updates the client permissions. no queue jumping, bestie.

for connections coming from applications running inside Flatpak, and not mediated by other clients (eg. portal or pipewire-pulse), the pipewire.access.portal.app_id property is set to the Flatpak application ID, if found. plus, pipewire.sec.flatpak is set to true. cute little receipts for the flatpak girlies 🌸

---

👑 MODULE NAME 👑

libpipewire-module-access

---

💅 MODULE OPTIONS 💅

options specific to the behavior of this module (yes, this is the girlboss section):

• access.socket = { "socket-name" = "access-value", ... } — socket-specific access permissions. it has the default value { "CORENAME-manager": "unrestricted" } where CORENAME is the name of the PipeWire core, usually pipewire-0. ✨
• access.legacy = true — enables backward-compatible access mode. cannot be enabled when using socket-based permissions. if access.socket is not specified, it has the default value true, otherwise false.

Warning 🚨 the legacy mode is deprecated. the default value is subject to change and the legacy mode may be removed in future PipeWire releases. like, it's on notice fr fr. 💀

---

🌈 GENERAL OPTIONS 🌈

options with well-known behavior:

• pipewire.access
• pipewire.client.access

---

🎀 CONFIG OVERRIDE 🎀

you can add a module.access.args config section to override the module arguments. yes queen, you get to rewrite the rules 💜

# ~/.config/pipewire/pipewire.conf.d/my-access-args.conf

module.access.args = {
     access.socket = {
         pipewire-0 = "default",
         pipewire-0-manager = "unrestricted",
     }
}

---

🔥 EXAMPLE CONFIGURATION 🔥

 context.modules = [
  {   name = libpipewire-module-access
      args = {
          # Use separate socket for session manager applications,
          # and pipewire-0 for usual applications.
          access.socket = {
              pipewire-0 = "default",
              pipewire-0-manager = "unrestricted",
          }
      }
  }
]

🦋 See also 🦋

• pw_resource_error
• pw_impl_client_update_permissions

---

aaand that's the whole page bestie, you ate it 🍓💖 this one's from PipeWire 1.6.11 — okay love you, bye, go secure some clients responsibly ✨🫶🧚