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
