On tis, 2014-12-16 at 09:48 +0530, Arun Raghavan wrote: > > On 15 Dec 2014 13:29, "Alexander Larsson" <[email protected]> wrote: > > > > On fre, 2014-12-12 at 17:42 +0100, Bastien Nocera wrote: > > > On Fri, 2014-12-12 at 17:08 +0100, Alexander Larsson wrote: > > > > On fre, 2014-11-28 at 16:07 +0100, Alexander Larsson wrote: > > > > > * Audio > > > > > > > > > > There is no audio support atm. Neither alsa libs, not device > nodes. > > > > > I think the best approach is to use pulseaudio, but this > needs > > > > > careful consideration in terms of ABI/IPC compat, > performance, > > > > > latency, etc. > > > > > > > > Today I looked at audio via pulseaudio. This is kind of tricky, > it seems > > > > to me like the pulseaudio protocol follows the X11 style > permissions > > > > method. I.e. if you're able to authenticate to the daemon you > have full > > > > privs, including loading modules into the daemon. > > > > > > > > Furthermore, the "normal" mode of using shared memory to send > audio > > > > relies on a single global /dev/shm, which breaks with any kind > of > > > > containerization and allows any client to read any other clients > data. > > > > > > > > I don't see why theoretically pulseaudio couldn't allow shared > memory > > > > buffers in a contained mode, via e.g. fd passing of the shared > memory > > > > instead of a shared namespace. However, anything like this > involves > > > > upstream changes to the protocol. For now i'm disabling shared > memory > > > > in the app, which is not ideal but at least allows apps to play > sounds. > > > > > > Lennart did mention that PulseAudio could make use of kdbus for > passing > > > buffers around, and I guess that Wim's "PulseVideo" (for the lack > of a > > > better name) could also make use of it. > > > > > > Finer permissions are necessary in any case. You can probably > allow any > > > app to play sound, but you might not want to allow microphone > access to > > > most applications. > > > > Yeah, this level of permissions will need some drastic changes to > the > > pulseaudio client handling. Perhaps it is possible to do while > keeping > > the protocol, not sure about that. But in general, a kdbus version > would > > be pretty nice as this would remove the issues around having to > > share /dev/shm with the host. > > Yes, kdbus is something that could be useful to plug this leak (though > we'd also need to make sure we don't add much overhead). In general, > securing the protocol is something we'd like to have, but is a huge > can of worms right now -- securing the protocol post-facto will be > hard to do right.
kdbus should have very nice performance characteristics for this kind of use, but yeah, there are always risks with switching to an unknown system. I wonder if it could be possible to support both a new protocol and the old one at the same time. Then one could ignore security concerns in the old one and force contained apps to use the new one. > Tanu was looking at a tunnel-based solution for containers in the mean > time. Maybe he can fill us in on this. This sounds interesting. _______________________________________________ gnome-os-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gnome-os-list
