On Thu, Jun 22, 2006 at 11:07:37PM +0200, martin f krafft wrote: [pam_console] > > devices when they log in on the console. Thus anyone who logs in > > automatically has access to the sound devices. However, this facility > > appears to be lacking in Sarge. > > by choice, yes. > > http://lists.debian.org/debian-devel/2001/06/msg00944.html
I agree the post's points are valid... However how is this any worse than adding all the users to the audio group (a solution recommended in that very message, and many other posts on various debian lists)? Either way, this is still possible... In my scenario, everyone who uses these machines would need to be added to the audio group. So there is no gain in security here by comparison. I would argue that pam_console is actually better, because it offers only the temporary ability to do this, and the user had to log in on the console to get the privilege in the first place. Using the group method, EVERYONE in the group can do this at any time, as long as the sound device isn't already open by someone else. Any such user can log in remotely and repeatedly open the sound device whenever any other user releases it... So, I don't see how you can argue that using a group is better than pam_console. And in any event, the only problem it causes is a DoS of that resource, which the system administrator can fix right quick, and can disable the account of the offending user. This is annoying, but it's not really a big deal, and the user can be dealt with in other ways. IIRC pam_console also has mechanisms to prevent it from working for specific users/groups, so there again, it would seem to be a better solution. I might be mistaken on that last point though; it's been years since I had any reason to configure it beyond Red Hat's defaults. But anyway... > check out pam_group and /etc/security/group.conf for another > approach, which is not secure (read comments), but a little better. Thanks for the tip... this may work, though at a quick glance, again, I don't see how this is better than pam_console. > You are probably using udev which creates them after boot. > > dpkg -l udev Yup. > > Anyone know how I can make this stop? Or alternately, know a > > different way to solve this which I have not already discussed? > > You could help with modularisation of makedev, which will allow you > to specify policies for device files. Is udev using makedev, or equivalent? If not, I would think that the better way to go would be to look into configuring policies in udev... In particular, it would be nice if whatever is managing the devices noticed that the device files exist already, and leave them alone if only the permissions and/or ownerships have changed. > dpkg -P udev Any potential gotchas to doing that? It might be the right solution for my purposes... > you get what you ask for. Now if you're not using devfs but a plain > /dev, you should be fine. FWIW, I didn't ask for udev. It appears to be the default... I'll need to read up on udev, and see what it provides. Been meaning to do that for a long time now... ;-) Thanks for your response, and thanks to everyone else who responded. It looks like a real solution to my problem is going to have to wait until I do a little more research, but at least I know what to look at now. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D
pgp2ra1OBTESf.pgp
Description: PGP signature
