Re: Solving the console permission problem [LONG]
In article <19991219182448.A24804@cesarb.dhis.net> you wrote:
> The console permission problem is something that everybody who has a sound
> card is used to...
I find this an interesting assertion, since I've been completely unaware that
a problem exists. In fact, after reading your note, I'm still not convinced
that there's a problem. As the maintainer of the 'makedev' package, this
general topic area is one which I *have* spent some time thinking about...
> which permissions should be set on /dev/dsp and the other audio
> devices so that they can be used as a normal user? The current solutions are:
> 1) -rw-rw-rw- root/audio
> This is the easiest one, but allows anyone that is logging in from a
> remote location to read from the mic or make embarassing or annoying
Clearly a bad idea.
> 2) Adding people to group audio
> This is also bad, since it's like above but restricted to a few people.
I don't understand this at all. Why is the set of people who you would give
access to audio devices not equal to the set of people you trust to not
embarrass you? This is the "solution" that is assumed for most things on a
Debian system. The whole point of different groups for different types of
devices that might need to be access-controlled is exactly this... so that you
can use group membership to control access rights.
> 6) Changing the uid of the audio files on login and changing them back to 0 on
> The best idea, but works only with xdm (and the one I use here)
> Solution 6 is the best so far...
Why is it ok for user X to have access to audio devices when they are on the
"console", but not when they are accessing the system remotely? If you trust
someone enough to give them physical access to your system console, then you
trust them essentially completely.
> I could do a sample implementation of this mess -- but only when I discover
> the low-level X calls needed for validating a user
Are "console" and "X" synonymous in your mind? They aren't in mine.
> Why adding this to Debian? Because it would make sound work "out of the box"
> (well, almost) while maintaining a strong security model.
I think sound does work out of the box in Debian. There are open topics of
discussion about whether video4linux devices and audio devices should be in
separate or the same access control groups, but that's a different topic.