Sound device permissions in Linux

[kylef]

I'm running customized kernel 2.4.18 with devfs under a Red Hat distribution.

I can't figure out how to properly set up sound device permissions so that the ONLY user (other than root) allowed access to /dev/sound/dsp and /dev/sound/mixer is the user currently logged into the console.

I know that there is a mechanism to implement this but I can't seem to find information about it. I do NOT want to use an "audio" group that allows other users to log in remotely and control the sound device from a remote machine (for obvious reasons).

Thanks for any pointers or RTFM rants, as long as they provide helpful links 🙂

 

[MGMorden]

I'm not sure if you can do this by simple permissions. The Unix permissions system is very simple. Either the owner of the file can read/write/execute, or the group, or all others (or any combo of those). The only way I'd see to do this is to write up some sort of daemon to run in the background and always have the local user own the sound devices (a very non-trivial solution). I could be wrong though.

 

[Tiger]

It all comes down to an admin problem.
The simplest way to do it add those users you want to have access to the sound system to the audio group.
If you've set up good paswwords and shadowed them you shouldn't worry about somebody breaking in the box and taking over the sound system.

 

[kylef]

I've seen this done before, so I know it's around. The trick is that there is some sort of tool that gets run by either X or XDM that automatically sets the permissions of the sound device upon login to the user that is logging in. On logout, the original permissions are restored.

Once setup, this is a MUCH cleaner way of implementing local device permissions than hacks such as establishing an "audio" group that has write access to the device.

No real operating system should allow multiple users to control console devices! You certainly should not have to rely on the "good naturedness" of the users...

If you've set up good paswwords and shadowed them you shouldn't worry about somebody breaking in the box and taking over the sound system.

It's not that I'm worried about people breaking in; it's that I'm worried about legitimate users abusing their control over a machine which they should not have... 🙂

 

[Tiger]

Hmmm,
Must be a custom script that gets kicked off in ~/xinitrc.

 

[EmperorRob]

Originally posted by: kylefOnce setup, this is a MUCH cleaner way of implementing local device permissions than hacks such as establishing an "audio" group that has write access to the device.

No real operating system should allow multiple users to control console devices! You certainly should not have to rely on the "good naturedness" of the users...

Actually I would say just the opposite. If you are letting root own /dev/audio, etc that means each time you login you'll have to have root permissions to change the permissions of that file, whereas an audio group permissions are static and no extra config is needed at boottime.

I use a similar solution with my share NFS files. Create a group that I grant access to and add certain users to that group.

 

[MGMorden]

I still think that the owneship changing daemon would be the best way to implement this. Now somebody just needs to write the darn software 🙂. I would do it but I've never written a daemon before. no experience. would be a nice project though. Of course by the time I finished it you'd have found another answer or given up on it entirely . . .

 

[Nothinman]

PAM can probably do it without the need for a daemon, I believe PAM already does this for /dev/console when you login on the console.