[pulseaudio-discuss] system-wide daemon

[Colin Guthrie]

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

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

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