Debian Bug report logs - #656910
Group "audio" is used for two incompatible things

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: David Henningsson <david.henningsson@canonical.com>

To: submit@bugs.debian.org

Subject: Group "audio" is used for two incompatible things

Date: Sun, 22 Jan 2012 21:02:00 +0100

Package: jackd2
Severity: normal
Version: 1.9.8~dfsg.1-1

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

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

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.

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.

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

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

Message #10 received at 656910@bugs.debian.org (full text, mbox, reply):

From: Adrian Knoth <adi@drcomp.erfurt.thur.de>

To: David Henningsson <david.henningsson@canonical.com>, 656910@bugs.debian.org

Subject: Re: Group "audio" is used for two incompatible things

Date: Mon, 23 Jan 2012 12:31:34 +0100

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@thur.de  	http://adi.thur.de	PGP/GPG: key via keyserver

Message #15 received at 656910@bugs.debian.org (full text, mbox, reply):

From: David Henningsson <david.henningsson@canonical.com>

To: Adrian Knoth <adi@drcomp.erfurt.thur.de>

Cc: 656910@bugs.debian.org

Subject: Re: Group "audio" is used for two incompatible things

Date: Mon, 23 Jan 2012 13:19:37 +0100

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

Message #20 received at 656910@bugs.debian.org (full text, mbox, reply):

From: Kaj Ailomaa <ailo.at@gmail.com>

To: 656910@bugs.debian.org

Subject: audio group is not a default group for users

Date: Tue, 24 Jan 2012 05:44:55 +0100

Now, first of all, let me apologize for cross-posting earlier. However, 
since it was adviced that comments would be done here, I will also put 
my case here.

It is not clear to me at this point if audio group is the best group to 
use for jack and realtime operation, but nevertheless, whatever it would 
be - would it be possible to add that as a default group for all users 
on Debian, and furthermore on Ubuntu?
I am not aware of what security issues it would present, so forgive me 
for being naive. I'm just figuring it would only be used when starting jack.
Pro/Semi Pro audio users may be a minority, but it's still a big bunch 
of users. And having an application like jack installable makes it seem 
illogical to not be able to use it in realtime mode after installing it 
without having to administer groups for users.

If that suggestion is impossible, what about adding group administration 
to the installation procedure of jack?

Nad, if using groups is not the best way, what would be?

Message #25 received at 656910@bugs.debian.org (full text, mbox, reply):

From: Adrian Knoth <adi@drcomp.erfurt.thur.de>

To: pkg-multimedia-maintainers@lists.alioth.debian.org

Cc: 656910@bugs.debian.org

Subject: RFC: Making realtime prios and audio orthogonal

Date: Tue, 24 Jan 2012 15:38:08 +0100

Hi!

As outlined in #656910, "being in the audio group" and "having realtime
priorities" aren't separated at the moment.

To make these two independent, we'd need to use a different (new?) group
for realtime priorities.

Any suggestions? rtaudio maybe? Current idea:

  - modify jackd1 and jackd2 to depend on some new package, e.g.
    jackd-common (provided by src:jack-defaults)

  - have jackd-common provide /etc/security/limits.d/rtaudio.conf

  - use adduser --system rtaudio in jackd-common's postinst scripts

  - maybe ask the user about adding user IDs to this new group


Do we have to coordinate with debian-devel about the group name?


Cheers

Message #30 received at 656910@bugs.debian.org (full text, mbox, reply):

From: Felipe Sateler <fsateler@debian.org>

Cc: pkg-multimedia-maintainers@lists.alioth.debian.org, 656910@bugs.debian.org

Subject: Re: RFC: Making realtime prios and audio orthogonal

Date: Tue, 24 Jan 2012 12:01:57 -0300

On Tue, Jan 24, 2012 at 11:38, Adrian Knoth <adi@drcomp.erfurt.thur.de> wrote:
> Hi!
>
> As outlined in #656910, "being in the audio group" and "having realtime
> priorities" aren't separated at the moment.
>
> To make these two independent, we'd need to use a different (new?) group
> for realtime priorities.
>
> Any suggestions? rtaudio maybe? Current idea:
>
>  - modify jackd1 and jackd2 to depend on some new package, e.g.
>    jackd-common (provided by src:jack-defaults)
>
>  - have jackd-common provide /etc/security/limits.d/rtaudio.conf
>
>  - use adduser --system rtaudio in jackd-common's postinst scripts
>
>  - maybe ask the user about adding user IDs to this new group
>
>
> Do we have to coordinate with debian-devel about the group name?

I think we should. There are probably other applications that need rt
priorities.

-- 

Saludos,
Felipe Sateler

Message #35 received at 656910@bugs.debian.org (full text, mbox, reply):

From: Kaj Ailomaa <ailo.at@gmail.com>

To: 656910@bugs.debian.org

Subject: replace memlock limited using a script to determine RAM size at each boot

Date: Wed, 25 Jan 2012 09:29:55 +0100

This is again not a subject for this bug, but could perhaps be a small 
addition to the jack-common package?

There has been some concern whether using memlock unlimited is safe, but 
in order to know what to set it to, for instance 95% of the memory size, 
you would first need to check the memory size, and then replace the 
value in the .conf file.
I don't know where such a script could live, but I assume somewhere in 
the early boot process.

Even just doing it once is probably not a good idea, since people add 
and remove memory now and again. Don't what implications there would be 
if the memory size is smaller than what is written in the conf file.

Send a report that this bug log contains spam.