Herman Robak wrote: > On Wed, 07 Jun 2006 23:30:44 +0200, Holger Levsen <[EMAIL PROTECTED]> wrote: > > > On Friday 02 June 2006 12:32, Eduardo Marcel Macan wrote: > >> AFAIK group audio is there for security, so that in a multiuser, > >> networked environment random users are not able to open the > >> microphone input remotely and listen to conversations taking place > >> around the computer. > > > > in the default debian-installer install, the user which gets created at > > installation is added to the audio group. So you have audio and "that > > security" as new users per default are not added to the audio group. > > But it is the wrong security model, as it does not fascilitate something > like "xhost +local:", i.e. granting locally logged in users to use the > sound device. I mean, what contrived use cases do we have where it is > NOT okay for the user at the console to use /dev/dsp? I am talking about > regular usage, not any real-time scheduling stuff. <snip>
You can sort of do this with pam_console; this adds users to a specific group if and only if they log in at the console. But that doesn't entirely solve the problem, because once you've granted access to a device you can never take it back again. A user who logs in once at the console can keep a process running and holding onto the device after they have logging out and gone away. I see two possibilities: first, use a daemon to mediate access to the audio devices, and have that implement such a policy; second, add a pseudo-audio-device facility to the kernel that allows for allocation of distinguishable devices when they log in and revokation of access to those devices when they log out. I think the former is more feasible. Ben. -- Ben Hutchings If more than one person is responsible for a bug, no one is at fault.
signature.asc
Description: This is a digitally signed message part
