[pulseaudio-discuss] Pull request: Autospawn fix

[Tanu Kaskinen]

ma, 2010-01-11 kello 15:03 +0000, Colin Guthrie kirjoitti:
> 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?

3 seems like the best choice, because option 1 alone makes it hard for
multiple users to use ssh simultaneously, and I don't see any big
problems with 3. It may or may not make sense adopt option 1 in addition
to 3. Are there any actual use cases for trying localhost TCP
automatically? Maybe on Windows...

I'd like to clarify the option 3 description: there should be a default
port in the sense that a certain port is always tried first if nothing
else is explicitly configured, but as a fallback the default port should
really be the first port in a range of default ports.

I also have a (semi) related note: currently connecting to the D-Bus
server using a non-default address/port requires setting up a separate
config entry in client.conf or a separate environment variable. This
should not be needed - the most common case for setting a custom server
string is to just set the hostname. That is easily converted to a D-Bus
address (for those who don't know, the conversion is needed, because
D-Bus uses addresses with format "tcp:host=HOSTNAME,port=PORT").

The problem is with non-default port numbers and non-default socket
files. I don't think maintaining separate config entries for different
protocols is sensible, so I'd like to extend the server string syntax.
When specifying TCP ports and socket files, the protocol type should be
specified. The syntax should be backwards-compatible - this is achieved
by assuming that if no protocol is specified, the native protocol is
meant.

This is an example from the wiki:

{ecstasy}unix:/tmp/pulse-6f7zfg/native tcp6:ecstasy.ring2.lan:4713 tcp:ecstasy.ring2.lan:4713

This is how it might look, if D-Bus settings are added (the actual
syntax is subject to discussion, I haven't thought hard what kind of
syntax would be the best):

{ecstasy}unix:[native]/tmp/pulse-6f7zfg/native,[dbus]/tmp/pulse-6f7zfg/dbus tcp6:ecstasy.ring2.lan:[native]4713,[dbus]24883 tcp:ecstasy.ring2.lan:[native]4713,[dbus]24883

Maybe this would make sense for the http protocol too?

In order to advertise the addresses correctly with module-x11-publish,
the core needs to have a new registry for server addresses. The protocol
modules would tell the registry that "a unix socket is available for
this protocol at this location", or "a tcp server listens connections
for this protocol on this host at this port". The registry would then
take care of merging all these advertisements so that each protocol
doesn't create a separate server string.

If this gets support, I volunteer to write the code.

-- 
Tanu Kaskinen