Date: Sun, 18 Jan 1998 13:31:20 -0800 From: Paul Traina <pst@juniper.net> To: dg@root.com Cc: bde@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: isdisk() kludge in kernel Message-ID: <199801182131.NAA08447@red.juniper.net> In-Reply-To: Your message of "Sat, 17 Jan 1998 16:24:46 PST." <199801180024.QAA16926@implode.root.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <199801180024.QAA16926@implode.root.com>, David Greenman writes: > >I was looking at isdisk and wanted to hurl chunks. > > > >This is used by spec_open to determine if we should be allowed to open a > >disk device when securelevel >= 1. > > > >I'd like to propose changing spec_open to simply NEVER allowing the open of > >a block device, or character device, if a character device has a block > >device associated with it and eliminate isdisk() in kern_conf entirely. > > > >Objections? (p.s. I found this in 2.2.5, haven't checked 3.0 yet to see if > >it was fixed, if it was, sorry for bothering you). > > I must be too tired or something: the above makes little sense to me. We > have block and character devices for disks for a reason. They are mutually > exclusive and both are required for the system to work. In both 2.2.25 and -current, there is code in spec_open() which restricts the opening of disk devices, both character AND block, if securelevel >= n. Currently, this code calls isdisk() to determine if a device is a disk device. isdisk() is evil. I was thinking of replacing isdisk() with a flags in the cdevsw/bdevsw structures (the right(tm) thing to do) but then thought some more about the semantics of the open, and decided that an acceptable alternate is to simply replace isdisk() inline code in spec_open() which restricts the opening of ALL block devices and ANY character device that also can be accessed as a block device. While this isn't as exact as having an explicit flag that says: "Hey, I'm a disk!" I'd rather change the semantics slightly and always get a reasonable default behavior, rather than rely on the drivers to "do the right thing" because they never do -- the problem is too distributed for it to be a clean security-worthy fix. Paul
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801182131.NAA08447>