Hi! On Sun, Aug 27, 2017 at 11:15 AM, Tanu Kaskinen <tanuk at iki.fi> wrote: > > On Wed, 2017-08-23 at 19:38 +0300, Lauren?iu Nicola wrote: > > Hi, > > > > The 9.0 release notes mention memfd as a SHM transport variant that can > > make Pulseaudio perform better when running in the system mode, but the > > implementation seems to disallow it [1]. > > > > I'm wondering if there still are plans to make this work. > > There hasn't been any decision to not make it work, but it seems > unlikely that anyone will actually do the work. > > Ahmed Darwish was the one who implemented the memfd transport and he > was interested in improving the system mode, but he hasn't been active > lately. I added him to Cc in case he wants to comment. > Exactly. The ambitious long-term vision was to make PulseAudio run in system mode by default. This was for multiple reasons: 1) Running PA in user login context makes a number of important use cases completely unfeasible. Basically the case when you want to consider your whole machine as an audio sink over the network, and not different _incompatible_ PA instances per users login and exit. Check this long discussion on the systemd list for more details http://article.gmane.org/gmane.comp.sysutils.systemd.devel/33574 2) The Linux desktop world is moving to containers anyway, and thus PA security needs to be done at the fine-grained level of each client connection rather than at the primitive level of users and UIDs. And if we achieve "(2)" above, then it would be secure to use SHM in system mode, since the same mechanisms used for protecting PA clients from each other will be re-used as is. It wouldn't matter if the apps under same or different UIDs :-) Problem is, unlike what Apple correctly did with its Core Audio services and APIs, PulseAudio completely ignored the inter-client security question. Its original design basically said, "the server and all its clients run under the same UID; cool, security issues solved". Ten years later, this design decision proved fatal: there are inter-client security pain points across the whole PA stack. I've summarized these problems here: https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/Developer/AccessControl Some of these issues were tackled by a proposed (now discontinued) access control layer to pulse by Wim Taymans, RedHat, for better Flatpak integration. Like memfds, this was also another "necessary, but not yet sufficient" part of the intractable PA security puzzle. Why? Because even if we got the access-layer merged, pulse uses a global mempool to pass recorded audio from server to clients, and for other small use-cases. And this global mempool is touched *almost everywhere* in the code base -- including quite esoteric and hard to debug modules. There were some plans to fix this, in an incremental manner, here: https://lists.freedesktop.org/archives/pulseaudio-discuss/2016-February/025477.html And if that was fixed, we still have another thorny issue: due to pulse "rewinds" design, any PA client, sandboxed or not, and even after merging access-control, can _reliably_ induce the kernel to kill the pulse daemon through normal and perfectly legal requests -- effectivey causing a global denial-of-service attack. I've written a sample of these legal but malicious clients here: https://github.com/a-darwish/malicious-pulseaudio-clients And that's why the pulse community does not encourage system mode and especially system-mode SHM to this day; except in very special cases like Yocto and OpenEmbedded-based devices. If the above mentioned problems are to be fixed, then activating system-mode SHM can be done safely. On having any plans to fix this, as Tanu said, I've been a bit inactive after getting memfds and its stability fixes merged: have been in the process of moving to Germany, which includes all the fun stuff of searching for a new home, job, etc. ;-) And it seems Wim's approach now is to create a new audio/video server replacing PulseAudio, which will handle all the security questions mentioned above from _day zero_, while maintaining compatibility with pulse APIs: https://github.com/PipeWire https://blogs.gnome.org/uraeus/2017/09/19/launching-pipewire IMHO, the above *is the only sane approach now* for solving the intractable PA security problem. So, short answer after this long message: no, it seems no one is going to solve this at the PA level anymore. Wait for pipewire, or manually enable this in the code base at your own risk. All the best, -- Darwish http://darwish.chasingpointers.com
