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
