[pulseaudio-discuss] Pull request: Autospawn fix

[Lennart Poettering]

On Mon, 11.01.10 15:03, Colin Guthrie (gmane at colin.guthr.ie) 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.

>  2. Do attempt to connect but do not fail on an unauthorised connection
> (which would also cover the case of a random app which is not PA
> listening on that socket effectively DoS'ing autospawn) thus allowing
> autospawn.

Nah, I am against this. Errors are errors, we shouldn't try to ignore
them.

>  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.

> Personally, with a longer term view for networking support etc, I think
> 1 or 3 are more appropriate. If we implement 2, if someone turns on
> anonymous access + tcp it can effectively DoS another user from
> autospawning PA too and can hang applications as by virtue of the other
> user being in active (on a single seat system) they wont have permission
> to output the sound and the streams will be corked).

Yes, 1+3 sounds reasonable. Both configurable but defaulting to what
you suggest.

Lennart

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