Bug#656910: Group "audio" is used for two incompatible things

[Adrian Knoth]

On Sun, Jan 22, 2012 at 09:02:00PM +0100, David Henningsson wrote:

> Package: jackd2

> The "audio" group has a special meaning in standard desktop usage -
> as defined in udev rules, it gives access to sound devices to users
> in that group, thereby overriding/complementing Consolekit's
> automatic permission assignment (which allows the current logged in
> user to have sound card access).

Nothing wrong about that so far, I'd say. Though I have to admit I don't
know what Consolekit does under the hood to grant access to sound cards.

Does it change permissions? Does it change ownership of the audio
device?


> As a result, it is normally not recommended to let a user be a part
> of the audio group.

How do you arrive at this conclusion? Who gave this recommendation?


> However, jackd2 uses the same group name for a different purpose: it
> enables (if user activates it on installation) the users in the
> audio group to run processes with rt priority and unlimited memory
> locking.

Exactly.

> This is problematic; as a reasonably common use case would be to
> actually make use of RT priority, but at the same time use
> ConsoleKit's built-in device assignment.

I'm not sure if I understand your paragraph correctly, but do you want
to say that nowadays people are usually not in the audio group, so the
mechanism of (ab)using @audio in /etc/security/limits.d/audio.conf will
no longer work?

> My suggestion is to rename "audio" to something else in jackd2.

Let's assume we change it to "foo", then the user needs to be part of
group "foo". Where's the advantage?


Side note: "in jackd2" is only half of the story, there's also "jackd1"
with the same magic. We intend to refactor this into jack-common one
day.


Cheers

-- 
mail: adi at thur.de  	http://adi.thur.de	PGP/GPG: key via keyserver