[pulseaudio-discuss] system-wide daemon

[Colin Guthrie]

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

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

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

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.


>From my perspective, I really don't see the point. I think the model
that allows random SSH users to access the sound hardware is
fundamentally broken in the first place.


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/]