[pulseaudio-discuss] Pull request: Autospawn fix

Colin Guthrie gmane at colin.guthr.ie
Wed Jan 13 14:15:04 PST 2010


'Twas brillig, and Lennart Poettering at 13/01/10 21:46 did gyre and gimble:
> On Wed, 13.01.10 21:40, Lennart Poettering (lennart at poettering.net) wrote:
>>>  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.

Cool :)

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

Sucky indeed. FWIW I don't think we should use totally random ports as
it makes it harder to open firewall ports to cope with PA... If we knew
PA always used e.g. 10000-10099 then we could open those ports easily.
It's maybe not really something we should worry about tho' as the ideal
situation is to teach SSH how to tunnel the connection just like it does
for X for the majority of network connection use cases.

Migration may suck for users who are used to turning on networking +
auth-anon (or even just copying their cookie) in paprefs and then using
PA remotely.... wonder how we can deal with that :s

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