Subject: Re: lseek(2) & read(2) on raw cd(4) device
To: None <tech-kern@netbsd.org>
From: Thor Lancelot Simon <tls@rek.tjls.com>
List: tech-kern
Date: 08/24/2000 20:16:54
On Fri, Aug 25, 2000 at 12:19:13AM +0200, Ignatios Souvatzis wrote:
> On Fri, Aug 25, 2000 at 12:10:18AM +0200, Sean Doran wrote:
> >
> > | # if (CDPART(bp->b_dev) != RAW_PART &&
> > |
> > | um, /dev/r?d[0-9]*[a-h] are raw partitions.
> > | /dev/?d[0-9]*[a-h] are block partitions.
> >
> > Uhm, "raw partitions" is a bad term; 'un-blocked interfaces' perhaps is clearer?
> >
> > RAW_PART (see above) is defined in places like this:
> >
> > ./arch/i386/include/disklabel.h:#define RAW_PART 3
> > /* raw partition: XX?d (XXX) */
> >
> > ./arch/alpha/include/disklabel.h:#define RAW_PART 2
> > /* raw partition: xx?c */
> >
> > So, having learned alot about the "BSD way" of lseek versus vnodes,
> > can anyone explain to me why we don't do bounds-checking on RAW_PART in
> > cdstrategy/sdstrategy/etc.?
>
> We can't because (at least for disks) we use it to read and write the disk
> label, when there isn't any.
Note that this is a significant security hole, violating the "securelevel"
model: disksubr neither bounds-checks nor checks for overlap on the raw
partition; worse, it doesn't check for overlap between *any* partitions,
with the result that even at securelevel 1, you can write a new disklabel
with a partition that overlaps the one on which you wish to modify immutable
binaries, and away you go.
We really need to move *all* disklabel-writing code into the kernel.