[pulseaudio-discuss] system-wide daemon

[Markus Rechberger]

On Tue, Feb 9, 2010 at 7:51 PM, Colin Guthrie <gmane at colin.guthr.ie> wrote:
> 'Twas brillig, and Markus Rechberger at 09/02/10 18:25 did gyre and gimble:
>>> 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.
>
> It's not the app that corks. The app's audio stream is corked for it and
> the app is told about this. The app does not have any choice in the matter.
>
>> 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.
>
> The "audio" group is a legacy and is no longer needed. ACLs on the audio
> device are far more flexible.
>
> Also this only controls *physical* access to the device nodes which
> requires hardware mixing support to actually drive independently. Most
> sound hardware does NOT support hardware mixing.
>
>>>> 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.
>
> Yes it was. iTunes mearly paused itself because that made sense from a
> UI perspective. The sound system didn't say "Pretty please stop playing
> or I'll cry and cry and cry", it basically held it's hand over it's
> mouth and said "this will be a whole lot easier if you don't scream".
>
>> Sending a notification to the App that it should go into a corking
>> mode (if requested by the app)
>> would be better.
>
> No it wouldn't. Corking is done by the sound system, not by the apps. If
> all apps *had* to implement corking support, then we'd have to
> reimplment *all* apps sound systems. That doesn't make any sense and
> besides, it's not a "preference" or a "nice to have", it's a
> dictatorship-driven "you have had your rights removed" system. This
> isn't something that is specific to PA, it's lower down the stack in
> console kit.
>
>>>> 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.
>
> Yeah you're right, noone would ever be that nasty.
>
>> Maybe you got hacked that way in the past and that's your experience,
>> I have never seen someone hacking a system like that.
>
> Nah, you're right, no one will ever think of doing it and even if they
> did there are probably less than a thousand different ways they could
> exploit this right? Hardly worth bothering about!!
>
>> But imagine even worse people who are in the videogroup are able to
>> enable the webcam! Doh!
>
> Incase you didn't realise the above two comments were sarcastic... your
> point is exactly correct tho'. I don't want any other user to be able to
> view my webcam! That's why the groups are no longer used for device
> access!!! ACLs controlled by console-kit are what permits a given user
> access ot the webcam on any half-way modern desktop. That's the whole
> point!!! Do not have any users in the video group, do not have any users
> in the audio group. In fact I'd go the whole hog and remove those groups
> completely!!
>
>> If someone writes down his password and pins it onto the wall the
>> hacker might know all the passwords - what a terrible
>> scenario!
>
> I don't disagree.... I'm not entirely sure what your point in relation
> to this discussion is tho'.
>
>
>> 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).
>
> So you transmit something in the clear and you are suprised that someone
> "hijacks" your data? Again the relevance to this discussion is lost on
> me I'm afraid.
>

the user sitting infront of it could listen to FM radio, while another
one is using the FM Transmit (line-out)
unit.
In your scenario such devices do not exist and are prohibited.

>> I see your 'designed' way just as a valid usecase as my one (which
>> basically was requested multiple times by multiple
>> people already).
>
> Personally I don't. The active user has control of the sound hardware.
> If the machine is "inactive" then a pseudo session can be registered
> (i.e. in the case of gdm login). If the active user (be it a real user
> or "gdm") decides he wants the audio from the lower level system then
> they should configure their system to recieve the audio via some kind of
> controlled IPC mechinism and play it back accordingly.
>
> Bypassing this layer and accessing things directly is not IMO a good
> design. Everything is possible with the appropriate mechanisms in place
> and no functionality is sacrificed, but you have to be prepared to
> accept that old approaches will not last forever nor survive the tests
> of time.

your scenario is definitely over engineered for many people out there.
I see your points and I see it as a valid scenario but as mentioned
not as a valid reason for hard restricting
users. On the other side the only way out of this dilemma is to set up
systemwide service
which pretty much cannot be done in a generic way with all
distributions which use PA due
random config paths and inherited configuration files.
As long as this isn't fixed I hope operating systems don't make a hard
dependency
on PA only so people can still jump back to the old behavior.

Best Regards,
Markus