TheAudioGroup
|
Size: 4062
Comment: practical rule
|
Size: 3188
Comment: Incorrect text removed, justification: Previous text was speculating in improvements to ConsoleKit that are unlikely to happen, and contained incorrect statements about how file permissions work.
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 3: | Line 3: |
| As a practical rule of thumb for debian and ubuntu systems, '''until consolekit supports it, there should be no users in the audio group'''. | As a practical rule of thumb for Debian and Ubuntu systems, '''there should be no users in the audio group'''. |
| Line 7: | Line 7: |
| Otherwise, switching to another user may leave him with blocked access to sound devices. | Otherwise, switching to another user may leave the new user without access to sound devices. |
| Line 41: | Line 41: |
!ConsoleKit has no proper support for the unix group permissions (memberships) of the logged in users, and thus to give access only conditionally. It will automatically grant any console user access to microphone and speakers if no user in the audio group is logged in. It is not possible to restrict e.g. microphone access for a user account that is created to run untrustable web applications (contained to that users permissions). OTOH, if a user with audio rights is logged in, !ConsoleKit completely fails to switch the access rights if the console user changes. Sharing, forwarding or using an audio device concurrently between different users will require that (gtk)sudo, some other user switching tool, or you will set up some additional things properly: http://www.mail-archive.com/pulseaudio-discuss@mail.0pointer.de/msg07317.html |
The short version
As a practical rule of thumb for Debian and Ubuntu systems, there should be no users in the audio group.
Being in the audio group is the same as having selected "use audio devices" under "User administration" -> "Advanced" -> "Privileges". In other words, this checkbox should not be checked.
Otherwise, switching to another user may leave the new user without access to sound devices.
Exceptions
- When you want a user to be able to access a sound card even if he is not logged in.
- When you're running a system-wide daemon that is never logged in but still needs sound card access
When you're running an old, now unsupported version of Ubuntu which does not have proper ConsoleKit integration (TODO: Look up and specify which versions of Ubuntu that is.)
- If you're running Jackd and need realtime privileges (see below)
Checking
Open a terminal and run this command:
fgrep -ie 'audio' /etc/group
This command should not lists any normal user, in fact, everything except "pulse" (which is reserved for system-wide usage of PulseAudio, and is normally not used) is a cause for concern.
Implications
If you decide you want the user to be in the Audio group, you should know that this user can access the sound card even if he is not logged in. And at the lowest level, only one user/application can grab access to the sound card at the same time.
So assume, for example, that user A is in the audio group is logged in, and is 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).
Or assume that B is sitting in front of the computer, not using the sound card at the moment. A, who is in the audio group, logs in remotely, and can now grab access to the sound card. Should A decide to do so, this means that B suddenly cannot play audio anymore while A is using it. A can also record from the sound cards inputs, so if the machine e g has a built-in microphone, A could in a sense "spy" on B.
Jack and real-time privileges
In recent versions of Ubuntu, when installing the Jack daemon, it optionally installs a file giving every user in the audio group real-time privileges, and possibilities to prevent program memory from being swapped. This can be necessary for running low-latency audio without drop-outs, but is bad from a security and stability point of view, as a process running with real-time privileges can lock up the entire system completely.
Why
The ConsoleKit daemon automatically switches access to the audio device according to the currently logged in user. It does so by setting access rights to the sound device nodes (i e everything under /dev/snd/* ). You can verify that by downloading the acl package, then running the "getfacl /dev/snd/* " terminal command, it should list the current logged in user as having read and write access.
Audio/TheAudioGroup (last edited 2013-01-17 13:19:34 by hd9483857)