[pulseaudio-discuss] Pull request: Autospawn fix

Colin Guthrie gmane at colin.guthr.ie
Mon Jan 11 07:03:53 PST 2010


'Twas brillig, and Tanu Kaskinen at 11/01/10 14:03 did gyre and gimble:
> Hi Lennart,
> 
> I have modified the daemon so that if --start is used, the start-up is
> aborted if there's a server address configured in client.conf, the X11
> properties or the PULSE_SERVER environment variable. The fix is in the
> "fixes" branch of my gitorious repo
> (http://gitorious.org/~tanuk/pulseaudio/tanuk-clone/commits/fixes). The
> branch is rebased against the current master, and contains two purely
> cosmetic fixes also.
> 
> I already notified you about this in irc a couple of days ago, but that
> may have gone unnoticed, so I thought maybe the mailing list is a more
> appropriate channel.

Nicely done :) I'll leave it to Lennart to pull to avoid confusion.

On a (semi) related note, I opened this yesterday:
http://pulseaudio.org/ticket/773

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


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

WDYT?

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mandriva Linux Contributor [http://www.mandriva.com/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]




More information about the pulseaudio-discuss mailing list