Re: gnome-sdk update and TODOs

[Alexander Larsson <alexl redhat com>]

On tis, 2014-12-16 at 09:48 +0530, Arun Raghavan wrote:
> On 15 Dec 2014 13:29, "Alexander Larsson" <alexl redhat com> 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.