wireplumber/docs/rst/daemon/configuration/access.rst
Torkel Niklasson 26f5fc11a6 permission-manager: Add core_permissions support
The core object (ID 0) is implicit in the PipeWire connection and never
appears in the permission manager's ObjectManager. Add a
core_permissions field to set explicit permissions on it independently
of default_permissions.
2026-04-29 08:20:55 +02:00

125 lines
3.4 KiB
ReStructuredText

.. _config_access:
Access configuration
====================
WirePlumber includes a "client access" policy which defines access control
rules for PipeWire clients.
Rules
-----
This policy can be configured with rules that can be used to match clients and
apply default permissions to them.
Example:
.. code-block::
access.rules = [
{
matches = [
{
access = "flatpak"
media.category = "Manager"
}
]
actions = {
update-props = {
access = "flatpak-manager"
default_permissions = "all",
}
}
}
{
matches = [
{
access = "flatpak"
}
]
actions = {
update-props = {
default_permissions = "rx"
}
}
}
]
Possible permissions are any combination of:
* ``r``: client is allowed to **read** objects, i.e. "see" them on the registry
and list their properties
* ``w``: client is allowed to **write** objects, i.e. call methods that modify
their state
* ``x``: client is allowed to **execute** methods on objects; the ``w`` flag
must also be present to call methods that modify the object
* ``m``: client is allowed to set **metadata** on objects
* ``l``: nodes of this client are allowed to **link** to other nodes that the
client can't "see" (i.e. the client doesn't have ``r`` permission on them)
The special value ``all`` is also supported and it is synonym for ``rwxm``
Permission Managers
-------------------
For more advanced use cases, WirePlumber supports *permission managers* that can
apply per-object permissions dynamically based on rules and object interests.
Permission managers are defined in the ``access.permission-managers`` section
and then referenced by name in ``access.rules``.
Example:
.. code-block::
access.permission-managers = [
{
name = "custom"
default_permissions = "all"
core_permissions = "rx"
rules = [
{
matches = [
{
media.class = "Audio/Source"
}
]
actions = {
set-permissions = "-"
}
}
]
}
]
access.rules = [
{
matches = [
{
application.name = "paplay"
}
]
actions = {
update-props = {
permission_manager_name = "custom"
}
}
}
]
Each permission manager supports the following properties:
* ``name``: (required) a unique name used to reference the manager from
``access.rules``
* ``default_permissions``: the fallback permissions applied to all objects
that don't match any rule (applied as ``PW_ID_ANY``)
* ``core_permissions``: permissions applied specifically to the PipeWire core
object (``PW_ID_CORE``, ID 0). This is useful when you want to allow a
client to interact with the core (e.g. enumerate objects, subscribe to
events) while restricting access to individual objects. If not set, the
``default_permissions`` value is used for the core as well.
* ``rules``: a list of match rules with ``set-permissions`` actions that
grant specific permissions to objects matching the given constraints
When both ``default_permissions`` and ``permission_manager_name`` are set in
a rule's ``update-props`` action, ``default_permissions`` takes precedence and
the permission manager is ignored.