On Fri, 15 Nov 2002, Sheldon Hearn wrote: > On (2002/11/15 09:48), Soeren Schmidt wrote: > > > > Don't you think it makes more sense for the kernel to start off with > > > more restrictive permissions, and have the administrator determine > > > whether more restrictive permissions are appropriate? > > > > Actually no I dont. > > The security aware admin will know (or should that be "should know" :) ) > > what to do to make a system secure. > > The avarage user that uses FreeBSD dont, and will get confused if the CDROM > > device doesn't appear to work (ie writeprotected). > > Well I think this goes against the grain of much of the work that's > happened recently.
It is just a bug. SCSI cd devices never had this bug, and acd devices don't have it in the non-devfs case. Average users don't depend on this bug since average users run RELENG_4 which doesn't have devfs. Some other devices have even more insecure permissions. Sound devices have mode 0666. This bugs is "documented" in the snd_security_hole variable name in MAKEDEV. For devfs, you can grep the kernel sources for 0666 to find similar security holes. There are an alarming number of 0666's. Most are for ptys where they are OK. The most obviously wrong ones are for rp. rp devices have mode 0666 in the devfs case. rp gets this wrong in the opposite direction in MAKEDEV -- it is missing a "umask 7" for the cua case, so its cua devices are not group readable. rp also gets the user and group wrong for the cua devices the devfs case, so world r/w permissions are necessary to grant even the usual access to uucp:dialer. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
