[MPlayer-dev-eng] [patch] prefer ALSA over OSS

Rich Felker dalias at aerifal.cx
Fri May 4 16:33:01 CEST 2007


On Fri, May 04, 2007 at 10:24:38AM +0200, Nicolas George wrote:
> Le quintidi 15 floréal, an CCXV, Bobby Bingham a écrit :
> > How is an "audio" group "just a hack"?  Isn't that the whole idea of
> > groups - if you want to restrict access to a file/device (eg /dev/dsp)
> > to a specific set of users, add those users to a group with access to
> > that device.  If you want all users to have access to it, then you can
> > just make it world writeable.
> > 
> > Where's the problem?  In what way do UNIX permissions get in the way?
> > Just set them once the way you like, and be done with it.
> 
> Imagine. You have a computer at home. Like any well behaved Unix computer,
> it stays on 24 hours a day, with a SSH server. Sometimes, your little
> brother comes to visit, and you have created him an account; since he likes
> to play with ScummVM, you have put him in the audio group.
> 
> Well, your little brother likes practical jokes: one night, at 3 in the
> morning, he just does "ssh your.computer mplayer /some/loud/music.mp3".

Groups are not a permanent property of a user, but a property of a
process, inherited by child processes. Naturally your little brother
could keep a background process alive with permissions to the audio
device, but this whole scenario is rather silly. Someone with physical
access to the console could just leave an alarm clock sitting behind
the computer, or leave a hidden microphone/recording device in the
room, or install a keyboard logger, etc. I don't think any of these
possibilities invalidate the unix permissions model.

If you really want to prevent the case you just described, you can
kill all processes owned by the user which still have the audio
group...

Also, turning off your speakers/mic when you don't need them is a good
idea for privacy/security and for conserving energy.

Rich



More information about the MPlayer-dev-eng mailing list