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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
