I'm now finished with Amarok

[Colin Guthrie]

'Twas brillig, and Thomas Lübking at 22/04/11 17:55 did gyre and gimble:
>> Any modern system uses console-kit and udev to apply ACLs, not groups
>> for permissions.
> Stupid question aside - does (and how) work console-kit for daemons with  
> restricted permissions?
> (or for me when i just login to VT1 and fire some mplayer)
> I mean, because running ck-launch-session will likely not do in this case,  
> will it?

For me, when I log in on VT1, I am already registered with CK, so I
don't need to do anything. By being the "ACTIVE" user on the system, it
means I have permission to use the audio devices (and several other
devices) and can launch mplayer just fine.

>> As I stated in another reply, adding users to the audio group will in
>> many cases break audio in the case of e.g. fast-user switching.
> In any case two applications try to open /dev/dsp directly or what?
> (I've never had any kind of audio issues with different users and just  
> tested to fire two mplayer instances from different accounts at the same  
> time - no problem and i thought this was entirely gone with alsa??!)

Pretty much, although /dev/dsp is a deprecated API on Linux. ALSA is
used these days (/dev/snd/*) and is the only officially supported API in
the Linux Kernel.

In theory there is some degree of support for two different users using
e.g. dmix or dsnoop via alsa, but really this issue should be handled
more gracefully. i.e. Do you really want the other user to type "sleep
30m; mplayer BrittenySpeares-All-Songs.mp3" and then lock their screen
and let you log in?? I wouldn't wish it on anyone, especially if you're
in the middle of a VoIP call for business etc.

Speaking of VoIP calls for business, you certainly wouldn't want the
other user to be able to snoop on your audio and record it... Only your
user should be allowed access to this sensitive information when you are
the one at the desk... Hell, if some unscrupulous daemon was able to
access your mic, it could record your keystrokes and make a pretty good
guess at the passwords you type just from the noise!

While that is a rather contrived example, you certainly want to handle
graceful handover of audio devices when the active session chances and
console-kit is the currently accepted way of doing this.

Why some distros want to disable CK I cannot comment, but unless they
replace it with something that does similar things, the "solution" of
adding users to the audio group will always be the wrong one from a
security and design point of view (even if it achieves a short-term
work-around - leaving my windows in my house open solves the problem of
me forgetting my keys, but that's not to say I'll adopt this policy
overall!)

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]