SNAP containers have two main "audio" security rules:
* audio-playback: the applications inside the container can
send audio samples into a sink
* audio-record: the applications inside the container can
get audio samples from a source
Also, old SNAP containers had the "pulseaudio" rule, which just
exposed the pulseaudio socket directly, without limits. This
is similar to the current Flatpak audio permissions.
In the pulseaudio days, a specific pulseaudio module was used
that checked the permissions given to the application and
allowed or forbade access to the pulseaudio operations.
With the change to pipewire, this functionality must be
implemented in pipewire-pulse to guarantee the sandbox
security.
This patch adds support for sandboxing permissions in the
pulseaudio module, and implements support for the SNAP audio
security model, thus forbiding a SNAP application to record
audio unless it has permissions to do so.
The current code for pipewire-pulseaudio checks the permissions
of the snap and adds three properties to each new client:
* pipewire.snap.id: contains the Snap ID of the client.
* pipewire.snap.audio.playback: its value is 'true' if the client
has permission to play audio, or 'false' if not.
* pipewire.snap.audio.record: its value is 'true' if the client
has permission to record audio, or 'false' if not.
These properties must be processed by wireplumber to add or
remove access permissions to the corresponding nodes. That
code is available in a separate patch: https://gitlab.freedesktop.org/pipewire/wireplumber/-/merge_requests/567
Handle extend == 0 and don't expand the array but return -ENOSPC.
This makes it possible to handle static arrays, make a function to
make this easier. Remove pw_array_add_fixed() now that we support
this with extend==0 and because it was not used.
Round up the required space to next extend so that the total allocated
size if always a multiple of the extend.
Make pw_array_add_ptr() check for allocation errors instead of crashing.
Try to use `media.name` as the display name for a node
when none of the other keys are found in its properties.
For example, `pw_stream_new_simple()` only sets `media.name`
on the created node object by default.
When freewheeling we will immediately schedule a new graph cycle when we
get a process call because the graph completed.
When the process call is not done, because of some xrun or
because some node was removed that causes the graph to fail completion,
The next cycle will happen after a timeout.
This timeout was calculated as the ideal wakeup time (after a quantum of
time) and would accumulate for each timeout. The result is that the
timeout ended up far in the future and would stall the freewheel driver
for a long time.
Fix this by always setting the next timeout to wakeup time + freewheel.timeout
seconds. Also add a config property for the timeout (10 seconds, like
jack2 by default).
Fix the following compiler warning:
| In file included from /usr/include/spa-0.2/spa/utils/dict.h:14,
| from ../src/util_pipewire_objects.c:15:
| /usr/include/spa-0.2/spa/utils/defs.h: In function 'spa_ptr_inside_and_aligned':
| /usr/include/spa-0.2/spa/utils/defs.h:275:56: error: conversion to 'long unsigned int' from 'long int' may change the sign of the result [-Werror=sign-conversion]
| 275 | #define SPA_PTR_ALIGNMENT(p,align) ((intptr_t)(p) & ((align)-1))
| | ^
| /usr/include/spa-0.2/spa/utils/defs.h:276:42: note: in expansion of macro 'SPA_PTR_ALIGNMENT'
| 276 | #define SPA_IS_ALIGNED(p,align) (SPA_PTR_ALIGNMENT(p,align) == 0)
| | ^~~~~~~~~~~~~~~~~
| /usr/include/spa-0.2/spa/utils/defs.h:308:13: note: in expansion of macro 'SPA_IS_ALIGNED'
| 308 | if (SPA_IS_ALIGNED(p2, align)) {
| | ^~~~~~~~~~~~~~
Only names in the `org.freedesktop.ReserveDevice1` namespace
are interesting for the purposes of device reservation, so
use `arg0namespace` in the dbus match rule to filter out others.
In multi-ASE configurations there can be multiple transports per device,
each corresponding to different channels.
Emit sink/source nodes for each BAP transport present.
Combine them into a single sink/source in the same way as we do for
device sets.
For multi-ASE configurations, BlueZ does the channel allocation itself,
and passes us the result in the ChannelAllocation parameter.
If it is present, don't do the allocation ourselves but use that value
instead.
If Supported_Max_Codec_Frames_Per_SDU is less than what is required by
Supported_Audio_Channel_Counts, override its value assuming the device
actually supports at least that. Needed for Creative Zen Hybrid Pro.
Fix default value for channel count bitmask.
Do relaxed parsing of RFCOMM commands for AG & HF roles, allowing
multiple commands in same buffer.
Use same parser code for all HFP/HSP AG/HF. Parse input in relaxed way,
as some devices emit spurious \n
Add a /core message to set the log level of the pulse-server.
An alternative would be to watch the settings metadata and follow the
server settings. This is however less flexible so the custom message
was chosen.
Add a function to check if a specfic custom log level has been defined
for a topic.
We can use this to dynamically check if we need to do the connection debug
messages.
We can also get rid of the conn.* pattern hack to disable connection
messages by default.
When there is no specific level for a topic we store the global log level
in the topic level. Make sure this invariant is preserved when the
the global log level is updated.
We can then simply update the log level after we processed the log level
string to update all topics.
This should also make it possible to just use the level from the topic
in all cases and remove a check.
Make sure the log level on the chained logger is the same as ours.
Makes PIPEWIRE_DEBUG=3 make run print debug again.
This used to work because the log level was parsed and set before the
loggers were created and chained, and so they all got the same level.
Now that the level can be changed with metadata at runtime, we can't
really update all past loggers so let the journal logger copy the
level itself.
Make the topic registration/unregistration threadsafe, as they can be
called from constructors of static objects which don't necessarily run
in the main loop thread.
