[pulseaudio-discuss] More on the native protocol complexity

[Tanu Kaskinen]

On Fri, 2010-04-23 at 13:36 +0200, Rafal Wojtczuk wrote:
> Hello,
> On Apr 5, Lennart wrote (about native protocol):
> > Note that the protocol is kinda complex, both because it grew
> > historically and because some parts have to be complex. i.e. the
> > timing/flow control logic is non-trivial. Reimplementing that won't be
> > fun.
> >
> > tbh I don't think the native protocol while it works quite well these
> > days is something that deserves to be reimplemented by other projects.
> 
> The problem is that for some tasks the complexity of the native protocol is
> prohibitive. Consider the following scenario (that I am trying to solve
> now):
> There are two [virtual btw] machines, VM_USER and VM_HOST. We want to allow
> users in VM_USER to play sound on the soundcard attached to VM_HOST. So, the
> obvious method is to run pulseaudio daemon in VM_HOST, and prepare client.conf 
> in VM_USER so that it connects pa clients to VM_HOST over the network. However,
> VM_HOST does not want to trust VM_USER more than necessary. VM_HOST does not
> want to give VM_USER full access to the native protocol capabilities (like
> PA_COMMAND_LOAD_MODULE), nor to give it a chance to exploit a potential bug 
> (logic one, or buffer overflow) in this 150K C-code protocol.

How about getting a cheap or free used computer running pulseaudio that
you hook the speakers to? Then use that via TCP from VM_USER. That way
you don't need to run pulseaudio on a top security machine.

-- 
Tanu