[pulseaudio-discuss] Pull request: Autospawn fix

[Lennart Poettering]

On Wed, 13.01.10 21:40, Lennart Poettering (lennart at poettering.net) wrote:

> > If a muli-user system allows one user to setup network support so he can
> > ssh to another machine, if a second user logs in, the current connection
> > code will try and connect to localhost via tcp prior to auto-spawning.
> > 
> > Sadly this connection will fail due to a permission problem (e.g. user b
> > is not allowed to access user a's PA) and this failure ends the
> > connection loop prior to the point autospawning would kick in thus
> > failing to load PA for poor user b.
> > 
> > 
> > So there is a problem here which can be solved in several ways.
> > 
> >  1. Do not attempt to connect to localhost via tcp at all during normal
> > startup.
> 
> Hmm, this is actually a security hole by some means i guess. Because
> access to the default PA port is not access controlled and so everyone
> who likes can listen on that port and auth is done only one way. Might
> make sense to drop this. Or at least make it configurable in
> client.conf and disable it by default.

I have implemented this now, since it was actually trivial.

> >  3. Do not have a "default" pulseaudio TCP port and thus do not try and
> > connect (like 1. but more far reaching). Currently only one user on a
> > system can load TCP, but if multiple users want to use it to SSH out and
> > run applications this is bad. The networking module should load and try
> > to listen on a pool of TCP ports (e.g. a range of numbers for
> > firewalling ease) As the TCP port number is put into the x11
> > PULSE_SERVER property, it doesn't actually matter that the number is
> > standard. The module should randomly pick numbers from the pool (or
> > count up) until it finds one it can use (e.g. not already bound).
> 
> Hmm, sounds reasonable to me. In fact the kernel will assign a port
> number automatically if the user binds to port 0. We should probably
> make that the default unless things are run in system mode or
> so. Should be a trivial fix.

Haven't implemented this now, because it requires API changes to
pa_socket_server_new_ipv4() and friends which kinda sucks.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4