[pulseaudio-discuss] Pulseaudio system wide mode design

[Tanu Kaskinen]

On Thu, 2019-10-17 at 12:56 +0200, Pali Rohár wrote:
> Hello,
> 
> there are repeated problems related to fact that pulseaudio is running
> under user session and every user spawns own pulseaudio process.
> 
> Only one process can have exclusive access to specific ALSA card.
> 
> Also only one process can create connection to bluetooth A2DP device.
> 
> Looking at pulseaudio design, which should abstract audio device and
> sound cards which are "shared" resources, it looks for me that it is
> something which should be managed by (central) point. And not by many,
> for every user one.
> 
> So what are the main problems which prevent usage of pulseaudio in
> system-wide mode. When in system would be running only instance of
> pulseaudio and all users would connect to that one instance?
> 
> I know only problem related to security, that any process which has
> access to pulseaudio socket can control audio settings of all other
> processes connected to pulseaudio. And also can load or unload any
> pulseaudio module.
> 
> But this can be easily fixable by implementing access control, e.g.
> users in pulseaudio-admin group would be able to control everything like
> before (including module loading) and users in pulseaudio-access group
> would be able to see and modify only streams which they created and
> would not be able to see other strings (or modify other properties).
> And also would not be able to load/unload modules.
> 
> Is there anything else which prevents moving pulseaudio into proper
> system wide mode?

You say that "this can be easily [fixed] by implementing access
control". I would agree, except with the "easily" part. There was an
effort to implement access control for supporting sandboxed
applications (primarily Flatpak), but that stalled due to lack of
reviewers... Wim Taymans was the last one working on it, but he's now
building PipeWire (I don't know if there's a cause and effect going on
here...). Implementing an access control system isn't that simple.

A comment on some of your specific suggestions: if users can only
control the streams they created, that sounds very limiting. Users
should be able to configure quite freely the hardware that is assigned
to the seat that the user is logged in to (surely they should at least
be able to control the volume!). And completely disabling module
loading isn't ideal either: users should be able to load null sinks or
network sinks as they wish, for example. There is need for per-user
settings, which I think the system server could very well manage, but
all that stuff needs implementation work.

I personally think you're probably right that a system daemon would be
better than a user daemon, but I have the impression that I'm in the
minority here. PipeWire chose the per-user model too, and when I
suggested that maybe the system daemon model would be better for the
same reasons you mentioned, that didn't get much support. People seem
to think that duplicating user management in the audio server when the
operating system already does it is ugly and complicated.

Improving the system mode in PulseAudio would be welcome (for example,
it would be easy to make hotplugging USB and bluetooth cards work even
with --disable-module-loading), but if you try to change the design in
major ways by adding an access control system, there are no guarantees
that the effort will get any further than the last time that was
attempted. Maybe it would be better to advocate the system mode to the
PipeWire project? It's supposed to some day replace PulseAudio anyway,
and it already has a lot of the access control infrastructure, since
secure access for sandboxed applications is built in from the
beginning.

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk