[pulseaudio-discuss] [PATCH 0/5] Add access control to protocol-native
david.henningsson at canonical.com
Fri Jul 17 06:02:04 PDT 2015
On 2015-04-07 17:13, Wim Taymans wrote:
> This is a new patch series that preplaces the previous patches regarding
> access control.
> After some experimentation, this patch series adds support for async access
> control checks, like when we need to ask for user input. The async support
> is implemented by exiting the command without reply and then when the reply
> becomes available, re-execute the command.
> There is an example access control module that shows how one could implement
> client specific access control checks.
> The patch also contains a small typo fix that can probably be applied
Thanks for this work. Apparently it's more relevant to me than I first
A few design thoughts that I think we need to resolve first before
1. Coupling between core and native-protocol. Right now the hooks are in
core, and mapped 1-to-1 (or? are there exceptions?) to PA_COMMAND_*.
Other options would be:
- Just have a "pa_hook access[PA_COMMAND_MAX]" in pa_core instead?
Then we could skip the long list of PA_ACCESS_HOOK_ constants. However,
the increased dependency between the native protocol and the pa_core
object might be undesirable.
- On the other side, we could have the "pa_hook
access[PA_COMMAND_MAX]" in pa_native_protocol instead. However, native
protocol instances could - at least in theory - come and go, so they
probably need stored somewhere more reachable anyhow...
To sum up, I feel that since the hooks are specific to the native
protocol, they should be put closer to that protocol, but I can't point
to a better place to put it.
2. In general, I like the async mechanism. We might want to consider
special constants, say, PA_HOOK_ASYNC and PA_HOOK_DENY to not abuse the
existing PA_HOOK_CANCEL and PA_HOOK_STOP constants, but I'm not sure.
3. I also wonder if we need to make more information available to the
hooks. E g, for allowing or blocking a stream moving somewhere, the hook
does now only know what stream it's blocking, not to where moving is
suggested. Maybe this is something that can be solved later though.
David Henningsson, Canonical Ltd.
More information about the pulseaudio-discuss