[pulseaudio-discuss] system-wide daemon

[Markus Rechberger]

On Tue, Feb 9, 2010 at 6:54 PM, Colin Guthrie <gmane at colin.guthr.ie> wrote:
> 'Twas brillig, and Markus Rechberger at 09/02/10 14:52 did gyre and gimble:
>>> Can you demonstrate this?
>>>
>>> In the past when I've tested this behaviour on OSX (it was quite a while
>>> ago) it behaves exactly as I described above, and I've literally just
>>> now re-tested this on a colleagues Mac (latest version):
>>>
>>>  1. Enable "Fast User Switching" (System Settings -> Accounts -> Login
>>> Options).
>>>  2. Login as user.
>>>  3. Fast user switch (top right, next to clock) to a different user.
>>>  4. With new user download and run e.g. VLC or iTunes.
>>>  5. Start playing  some tunes.
>>>  6. Fast user switch back to your original user.
>>>  7. Note the blissful silence.
>>>  8. Do whatever you like with the original user login. Play tunes, check
>>> mail etc.
>>>  9. Switch back to the user who *was* playing.
>>>  10. If you used iTunes, it will now be in the Pause state so will be
>>> quiet. If you used VLC the music will continue playing now the user is
>>> active again.
>>>
>>
>> 1. default Mac from a company
>> 2. open a terminal and play an mp3 with mplayer as normal user
>> 3. going to another PC and logging in with ssh (as root) and playing
>> an mp3 ) -- works
>> 4. again going to another PC and in order you cannot blame it on login
>> as root I added another user and played back another mp3 -- it worked
>> too
>> in any case 2 different users were playing back the mp3.
>
>
> This is a totally different scenario to what we were discussing. Please
> try to keep this discussion on topic rather than twisting it to suit
> your particular bugbear.
>
> We've discussed to death the the technical reasons why *simultaneous*
> output from multiple users is not supported and I've shown by example
> that this is the exact same basic behaviour as on OSX with regards to
> multiple users.
>
> You've taken a different example showing that for some bizarre reason, a
> user (root or otherwise) is permitted access to the sound hardware on OSX.
>
> If this is possible (and I have no reason to doubt you) then this is
> simply something that I would argue very strongly *against* wanting to
> support in PA. A random SSH user should *never* have access to various
> h/w devices on my machine. A security model that supports this is broken
> IMHO, regardless of the 0.01% of niche cases where people would like to
> use it.
>
>>> I guess the reason there is a difference between iTunes and VLC is that
>>> iTunes presumably listens to the "cork" notifications from CoreAudio and
>>> issues an application level pause, whereas VLC does not and thus is
>>> forcibly corked, but will automatically play again.
>>>
>>
>> maybe iTunes is requesting this, but then hey this option would be on
>> enduser application level and not at audio stack level.
>
> iTunes *requests* nothing. It simply *adheres* to what it has been told
> is happening. The same would be true of any application that listens to
> the PulseAudio generated cork notifications (IOW what iTunes and VLC are
> doing is nigh on identical to what a native PA client can do - i.e. a PA
> client that listens for and takes action on cork notifications will
> behave like iTunes, one that doesn't have any specific support for
> corking will behave like VLC).
>

something must tell the app to 'cork' in OSX but it it no hard requirement.
By the way normally only the users who are in the audio group are
allowed to access audio (not entirely sure how this is handled with
osx though), so it's not like a random user is allowed to access the
audio device.

>> Seen from my side setting this option (the possibility to lock audio
>> to one user) on App level instead of Stack level this would be much
>> better.
>
> No idea what you mean here, but if you are think that I was suggesting
> some kind of "iTunes is more capable than VLC" then that's not really
> what I'm saying. Both are subject to exactly the same restrictions, it's
> just that iTunes presents it to the user by pausing itself and VLC does
> not. If iTunes had not paused itself it still would not have been able
> to output audio - the core fact does not change - it's simply dealing
> with the "you are barred from producing audio" signal that CoreAudio
> generated in a more user friendly way.
>

well something must have told iTunes to pause, but it definitely was
not the audio
stack which forced iTunes to stop or be silent.
Sending a notification to the App that it should go into a corking
mode (if requested by the app)
would be better.

>>> This is *exactly* the same behaviour as we promote in PulseAudio too.
>>>
>>
>> unfortunately I can not confirm this with iTunes either... I tested
>> this with OSX 10.4 and OSX 10.5.
>>
>> using iTunes and logging in remotely also worked - including audio
>> playback. I can make a video of this if you don't believe it heh.
>
> It doesn't matter if I believe it or not, the fact is that this part of
> the model is fundamentally broken and insecure. I mean someone roots
> your machine (running as "nobody" or "apache" via some week vuln in
> something or other) and all of a sudden they can eavesdrop on all your
> VoIP connections??? No thank you.
>

of course people will capture the audio device, this is a scenario
which is 99.9% unlikely.
Maybe you got hacked that way in the past and that's your experience,
I have never seen someone hacking a system like that.
But imagine even worse people who are in the videogroup are able to
enable the webcam! Doh!
If someone writes down his password and pins it onto the wall the
hacker might know all the passwords - what a terrible
scenario!
How about a FM USB Transceiver which uses UAC (USB Audio Class)
Why the heck should only the person sitting infront of it be allowed to use it
The person sitting infront of it could listen to audio while another
one could transmit audio (I do have such an engineering sample here).

> At all user facing levels, for the 99.9% use case of desktop users, we
> behave exactly the same as OSX. In the niche case of SSH user logging
> in, we DO NOT support the SSH user having control of our sound hardware,
> and for good reason.
>
> If you wanted this second senario to be supported you would have to:
>
>  1) Convince the people in charge that this is a good idea.
>  2) Design a new layer that runs as a system service and takes exclusive
> control of the physical sound h/w. This would have to support the PA
> glitch-free driving mechanism.
>  3) Define a method of authenticating users to access this system
> service when appropriate (i.e. whenever console kit says the user is
> "active").
>  4) Define a zero-copy, lock-free system to pass the audio from client
> -> local-server -> system-service.
>  5) Convince the ConsoleKit people that SSH sessions count as "active"
> users.
>

I see your 'designed' way just as a valid usecase as my one (which
basically was requested multiple times by multiple
people already).
Sometimes the best theoretical solution is not the best practical one,
and PA is a good candidate for that, if I look at MacOSX the system
has alot issues and the software might not even be the best designed
one but it works in a good acceptable way.

You should better acknowledge the requests of other people and think
about how to improve it instead of trying to hit it down permanently.
It is you guys working on it and other people are giving you feedback
what is or would be required.
By default I use to remove Pulseaudio nowadays, but it becomes
annoying to remove it everytime I install a system so I'd prefer to
have a PA solution which works out of the box. The PA configuration is
too difficult, and since I change the systems quite frequently I'm not
really up to permanently struggling around with that, maybe it's just
too much that I use to consider that audio has to work out of the box
for me..

Best Regards,
Markus Rechberger