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

[David Henningsson]

On 01/23/2012 12:31 PM, Adrian Knoth wrote:
> 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?

It sets ACL file permissions on the sound device nodes. A while ago, I 
wrote a little more of background information/conclusions here: 
https://wiki.ubuntu.com/Audio/TheAudioGroup (though I didn't add the 
word "Debian" there, that was done by somebody else)

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

I believe it to be the conclusion of both PulseAudio developers, and 
Ubuntu audio developers team. I consider myself to be part of both those 
teams.

Assume, for example, that user A is in the audio group, logged in, and 
playing music. User B wants the computer temporarily, so they switch 
users (via fast-user-switching, without user A logging out). Since A can 
still use the sound card, A's music will continue to play and user B 
can't access the sound card (regardless of whether B is in the audio 
group or not).

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

Worse; making a user part of the audio group will lead to the problem 
described above (changed behaviour of fast-user-switching). There might 
be times where this is desired, but let's reserve the "audio" group for 
those cases - without implying that on everybody who wants to run RT 
prio processes.

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

Hopefully the explanations above answer this question as well?

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

Ok, good point. I didn't check jackd1.

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic