Skip site navigation (1)Skip section navigation (2)
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>