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 _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
